inconsistency in auto-assgned request.uri variable between request and response flow breaking caching?

Not applicable

Hi - we are trying to do some work in edge w/ caching and we are seeing a rather interesting behavior:

the request.uri is being defined differently in the REQUEST and RESPONSE flows - hence the cache key is being defined differently and response cache misses are happening when they should not be.

lets say a request is being made to the following:

https://myhostname/myproxy/api/somepath?xy7

In the REQUEST flow the REQUEST URI will show up as:

/api/somepath?xy7

in the RESPONSE flow the REQUEST URI will show up as :

myproxy/api/somepath?zxy7

This is making us see inconsistent results out of Apigee.

0 9 297
9 REPLIES 9

HI @Benjamin Goldman - Which URI are you trying to use as Cache Key, the proxy URI or the Target URI ?

request.uri. it exists in both flows, but is different.

@Benjamin Goldman

Since the request object is used within the proxy flow and the target flow, the value of request.uri is changed.

If you want to use the proxy url as the Cache Key, you can use the message.* or the proxy.* flow variables and define the Cache Key. You can find the flow variables here.

Would recommend to use proxy.* or message.* over request and response variables for such use cases as most of these variables are read scopes and cant be re-written

You can club multiple variables to create a unique identifier as key.

so i have to be honest - it seems that you are telling me that they are different - but not telling me why.

Why does the response flow need request.uri to have the proxy name on the front, but the request flow doesnt?

How does that actually make sense and why isnt it a bug?

We already have a work around (we built our own variable) but this honestly has us all puzzled.

If you look at the doc here, please see the scope, there are some with Proxy Request/Response and some with Target Request/Response. This variable is across proxy and target but changes according to the flow.

As per the docs, it says Scope: Proxy Request which is misleading.

@Benjamin Goldman - Team have updated the docs. Hopefully the docs should not mislead now. You can leverage the other flow variables as per my comments above. Let me know if this answers your question.

@Floyd Jones / @wwitman - Can you please take a look at this and update doc accordingly.

Hey @Sai Saran Vaidyanathan - As described in that topic, scope refers to where the variable is first available. For clarity, I've changed "Scope" to "Scope begins" in the variable descriptions.

Thanks @Floyd Jones