When a client browser receives a 302 response, does the browser modify or ignore any parameters appended to the end of the URL?
For example, I have a server that redirects requests to a different URL but retains any parameters from the original URL and appends to the end of the new redirect URL. However, browser is not including the parameters in the new URL.
For example, if a request comes in to "https://server1.com/path1?filter=value", the redirect server responds with a 302 and "location: https://server2.com/path2?filter=value". But, issue is that the client browser seems to only recognize "https://server2.com/path2".
Should parameter values be tagged a different way in the response?
As noted by Remy Lebeau in the comments to the question, the browser does not modify the location URL in the 302 response. Rather, the issue was caused by the networking in AWS - I was using AWS Lambda to perform the re-direct by reading in the URL on the original request coming in and re-directing according to mapping in the function. First issue was that API gateway was stripping off the query parameters before it was hitting the Lambda function. Second issue was that the function read the "rawPath" attribute from the request, but this does not contain URL query parameters; the query parameters are contained in the "rawQueryString" attribute instead.
Related
I have an ASP.NET website. A user can access the URL /partners/{partner-id} in my app. When that url is invoked, I do two things:
1) I want to log the partner ID and user that requested it and
2) Redirect the url to the partner's website.
My question is, which HTTP Status Code should I use? I was using 301. However, that introduced a problem where my logging code was getting skipped. I suspect its because a 301 represents a permanent redirect. However, I basically want to remain the middle man so that I properly log the details.
What HTTP status code should I use?
Thanks!
Taking a look here:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
you should use the 302 status code. Two useful points about the 302 redirect:
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests
This says by inferring that the redirect may be temporary, clients should always check the initial URI instead of going to the redirect URI as a default behavior, meaning they will pass through your logging system each time rather than going directly to the redirected URI on subsequent requests. The 302 response also states:
This response is only cacheable if indicated by a Cache-Control or
Expires header field.
By default, the 301 redirect is cacheable unless you explicitly specify, but the 302 is not cacheable unless explicitly specified.
However, it's probably a good idea to explicitly add in 'do not cache' headers to the redirect to let the client know that it should not be cached just in case you have a client that doesn't follow the default spec behavior. There are a number of other answers in stackoverflow regarding this, here's a decent one:
How to control web page caching, across all browsers?
Is it possible for requests to the API-Gateway to pass the referrer URL to Lambda? For example, I'd love to let my lambda functions know if a request comes from the domain "good.com" vs. "bad.com".
I'm familiar with the list of supported $context Variables and I know a referrer url is not in there. I'm wondering if there is another way. If it is possible, what steps do I need to take?
Here's how to do it.
As it turns out, the mapping template allows you to map HTTP headers, not just the list of supported variables in the documentation.
The HTTP header that contains the referrer domain is called "Origin". The header that contains the referer page URL is called "Referer".
So, for example, you can put this in your mapping template and it will grab the associated header information:
{
"origin" : "$input.params('origin')",
"referer" : "$input.params('referer')"
}
Origin grabs example.com. Referer grabs example.com/pagename
It's an HTTP header, so if you are mapping HTTP headers in the template it will be passed to the Lambda function. Look at this answer for an example of how to map HTTP headers in the request template.
I am trying to record a simple login and logout flow for a .Net application. After I submit the login credentials the welcome page's URL has a large alpha numeric number. This number is required to continue to the next steps.
On Fiddler I have noticed that the login credential submission request results in a 302 response and this response contain an a=129characterstring that i need in my subsequent requests.
On JMeter I have added a recording controller and on the HTTP(S) Test Script Recorder I have Follow Redirects and Use KeepAlive checked (See below screenshot)
I have also recorded with Follow Redirects unchecked and different options for Grouping and HTTP Sampler Settings.
But with none of them I am able to record/capture the 302 response that i see on fiddler. Instead the login credential submission request always returns a 200 response, even if the login fails.
It is not as if that JMeter is not recording redirect requests, further down the scenario flow I have another redirect request which is captured.
I can't be the only one who is/has faced this problem. Does anyone have any suggestions on what I should be doing differently to get the 302 response?
To do this:
Record with default options, the redirect Http Request triggered by 302 will be disabled by default.
Then you will need after this to uncheck "Follow Redirect" in the first one, and add a Regular Expression Post Processor to extract the data you want.
Then enable the commented second request and inject the extracted variable.
We're working on a URL shortener project in PHP. We're using 301 HTTP redirection and naturally track our links visits. but there is something strange :
After we shorten a URL and go through it by a browser, only the first visit is tracked, and it seems that no other request is sent to our server and it directly goes to the destination URL.(I think this is a browser cache after one try). But :
When trying with a similar service like bitly , it has different treat. some of the same requests on the same browsers are tracked in bitly visit tracking (In fact more than one of them, and I don't understand why, I don't see any logic) while they also use 301 redirection.(at left bottom of browser window sometimes writes "waiting for bit.ly..." and sometimes not , in fact randomly).
Are any tricks included here? What this different treat happens?
Read the HTTP specification. A 301 response tells the browser that the requested resource has permanantly moved to the new URL that is being redirected to, and should not use the original URL anymore:
10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and
any future references to this resource SHOULD use one of the
returned URIs. Clients with link editing capabilities ought to
automatically re-link references to the Request-URI to one or more
of the new references returned by the server, where possible. This
response is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.
For what you are attempting, try using 302, 303, or 307 instead.
10.3.3 302 Found
The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field.
The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
If the 302 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
.
10.3.4 303 See Other
The response to the request can be found under a different URI and
SHOULD be retrieved using a GET method on that resource. This method
exists primarily to allow the output of a POST-activated script to
redirect the user agent to a selected resource. The new URI is not a
substitute reference for the originally requested resource. The 303
response MUST NOT be cached, but the response to the second
(redirected) request might be cacheable.
The different URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
Note: Many pre-HTTP/1.1 user agents do not understand the 303
status. When interoperability with such clients is a concern, the
302 status code may be used instead, since most user agents react
to a 302 response as described here for 303.
.
10.3.8 307 Temporary Redirect
The requested resource resides temporarily under a different URI.
Since the redirection MAY be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field.
The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s) , since many pre-HTTP/1.1 user agents do not
understand the 307 status. Therefore, the note SHOULD contain the
information necessary for a user to repeat the original request on
the new URI.
If the 307 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Just to note down my comments..
Cache control headers also plays a role on this. If you check with curl or firebug persistant tracking, you can see the cache control headers before the location. bitly is configured to be contacted back if user clicks on the links after 90 seconds.
I used HttpClient and GetMethod to get the page source of the URL :
http://www.google.com/finance?chdnp=1&chdd=1&chds=1&chdv=1&chvs=Logarithmic&chdeh=0&chdet=1264263288788&chddm=391&chddi=120&chls=Ohlc&q=NSE:.NSEI&
But somehow I always end up getting page source of :
http://www.google.com/finance?q=NSE:.NSEI
Can anyone tell me why and how to get page source of the former URL?
I'm going to go out on a limb here and assume that what's going on is that your HttpClient implementation handles HTTP redirects internally and so when you call GetMethod on the first URL, the server (google.com) is probably sending back an HTTP redirect (302, or 301) response for the second URL which is what you end up getting back.
The reason for that is probably that the first URL requires some sort of cookie which you're not providing when you make your request. The best way to determine exactly what happens when you make the request that way is to use a tool such as WireShark or Fiddler to analyse the HTTP request/response sequence from your HttpClient and that of a normal request made using FireFox or IE and see what exactly is different.