Does the browser make a new request to the location given in the header?
I ask because I was playing around with Fiddler and noticed when I make a request to a page that returns a 302 HTTP code, there are two entries in the network log. The first is to the initial URL, and the second is to the new location given in the response header of the first request.
I'm just curious if web browsers work the same way, but just hide the first response from the user.
Yes, the browser works in very much similar fashion. You can try requesting a url in Chrome, possibly the one you tried in Fiddler. The Network Log of chrome would show you two requests.
The RFC description of HTTP status code can be read over here,
Quoting from there only, regarding the 302 status code:
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.
When a server responds with a 302 status code, it send back the newer url (to which the current requested old url is to be redirected) to the requesting user-agent (likely a browser). Now, as per the RFC document, the user agent must not request the newer url for 302 status code. Yet most of them do make a second request.
Hope-this-helps.
Related
Using express JS I'm trying to add some headers to the redirection I'm returning
However, everything I tried just work for the response headers and not for the request headers of the redirection. I.E., when inspecting it with the developer tools I can see the response headers but when the next call is made, I can not see the request headers
req.headers['x-custom-header'] = 'value'
res.setHeader('x-custom-header', 'value')
res.redirect('example.com')
Does anybody could explain how the response and request headers work on ExpressJS?
A redirect just does a redirect. It tells the browser to go to that new location with standard, non-custom headers. You cannot set custom headers on the next request after the redirect. The browser simply doesn't do that.
The usual way to pass some type of parameters in a redirect is to put them in a query string for the redirect URL or, in some cases, to put them in a cookie. In both cases of query string parameters and data in a cookie, those will be available to your server when the browser sends you the request for the redirected URL.
It also may be worth revisiting why you're redirecting in the first place and perhaps there's a different flow of data/urls that doesn't need to redirect in the first place. We'd have to know a lot more about what this actual operation is trying to accomplish to make suggestions there.
If your request is being processed by an Ajax call, then you can program the code receiving the results of the Ajax call to do anything you want it to do (including add custom headers), but if it's the browser processing the redirect and changing the page URL to load a new page, it won't pay any attention to custom headers on the redirect response.
Can anybody explain how the response and request headers work on ExpressJS?
Express is doing exactly what you told it to do. It's attaching the custom headers to the response that goes back to the browser. It's the browser that does not attach those same headers to the next request to the redirected URL. So, this isn't an Express thing, it's a browser thing.
Why would #1 work, but not #2 or 3 when used in a $$Return field if database is being accessed using IE11? The field is hidden.
[db_path/db_filename/Page?OpenPage]
http://server_dns/db_path/db_filename/Page?OpenPage
server_dns/db_path/db_filename/Page?OpenPage
A URL in brackets (e.g., [db_path/db_filename/Page?OpenPage]) is interpreted by the Domino server as a command to send an HTTP 30x REDIRECT response (probably a 303, but I'm not sure) to the browser. Upon receipt of this response, the browser interprets it as an instruction to retrieve the specified URL. That's simply a matter of compliance with standards, so all browsers will do it.
The other choices you list are not treated as anything special by the Domino server. They are simply sent as ordinary content in a 200 OK response to the browser's POST request. No standards apply to this, so a browser may or may not choose to recognize that the response text looks like a URL and may or may not choose to do something with it - e.g., follow the link. Based on your question, it appears that IE11 does not do anything with it. It doesn't follow the URL. Frankly, I had no idea that any browser would do actually follow a URL if it is received as the sole content with a 200 OK response.
I am looking at my IIS web log and notice some log records with an sc-status of 302.
I did research and am only more confused.
At first, it looks simple, if a little vague.
"This is an example of industry practice contradicting the standard.
[...] Therefore, HTTP/1.1 added status codes 303 and 307 to
distinguish between the two behaviours.[25] However, some Web
applications and frameworks use the 302 status code as if it were the
303."
While I understand the concept, I am not sure which meaning to apply when viewing an IIS web log. Do I treat the 302 status code as a 303 ("See Other" -- a way to redirect to a new URL) or as a 307 ("Temporary Redirect")?
307 causes a redirect using the same "verb" that the original url was requested with. That allows POST data to be preserved. By contrast, 301/302 will always cause a GET of the new url, losing any POST data that may have been present.
As well, with 301/302, the browser can cache the response and always go to the new url, bypassing the original url. 307 requires that the original URL be hit again, even if it does end up being another redirect.
The standard res.redirect('/some/path'); behaves as expected and immediately redirects the request to /some/path, but if I add a status code, e.g., res.redirect(401, '/some/path') and I navigate to the redirecting page, express doesn't redirect to /some/path, instead I just get the following page:
<p>Unauthorized. Redirecting to /</p>
and it never redirects. This is the same for any status code I supply just by the way.
Why doesn't a code specified redirect work as I'm expecting it to and how can I return a custom status code and redirect to a different path?
The behavior of the Location header, which is used to to redirect someone, is only defined for status codes in the 3xx range, and for 201/202 statuses. Since you are setting the status code to 401, it is ignoring the header and just rendering the response content. It just happens that Express includes some nice text explaining that the user is being redirected in case the redirect is slow.
Also, given the definition of the 401 status code, you are likely misusing it. The 401 code is to let the client know that it needs to send additional authentication information with a give request, e.g. http://en.wikipedia.org/wiki/Basic_access_authentication, so you should not be redirecting to another URL.
I'm building a little email server based on nodeJS (homework). When a user tries to login I check that he has an account and then redirect him to /user/userName.
I set the response status to 201 Created, and then added a header Location: /user/userName
I checked in chrome's developer tools that the response was what I sent and it was, yet the location does not change. Any ideas why, or how to do it better?
Thanks
The HTTP response code for a permanent redirect is 301, not 201. Your browser will not use the location header to redirect you with a 201. Before you change to 301, though, make sure you don't want a temporary redirect, or 302, instead!