Re: [XHR] Redirects
This is a almost 2 year old thread but I am actually looking in implementing some tools that can only work in 100% of the cases if it is possible for XHR not to follow the redirects. I am not sure why this has been dropped but I think it would be time to bring it back. I think we can agree that being able to read and process the redirects in some way under some limitations, it is far better than not being able to do it at all like it is happening today. I am not an expert of XHR but I read through the posts and this is my proposal to which you can feel free to make changes of any kind. *Instead* of adding a followRedirect true/false, add a processRedirects function. If it is NOT defined the browser keeps behaving how it is currently doing today. If it is defined, the function is called after reading the page and before reading the next page specified by the redirect. processRedirects can return false to say the browser not to follow the redirect. If the function return true, the browser move to the next request and once it completes, it call again processRedirects and so on till the final destination. processRedirects should receives in some way the XHR object, the ordinal number of the redirects followed so far, any other things that makes simple to use read the Location with any other data/header from the server. If it works only in async calls, it should be Ok. Let me know what you think. And I hope that sooner than later we will be able to do a request at the time without necessarily having to follow the redirects. Best, Chris
Re: [XHR] Redirects
On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke julian.resc...@gmx.de wrote: I think that obtaining the resolved Location for the redirect is the most tricky part, and we should come up with a solution where that is also available for people who do not want the default browser behavior. I don't really like special casing the Location header here. It seems we are ending up with two additional members for dealing with redirects. I do not want another one. There are other headers where resolving a URL might be needed. Adding a parameter to navigator.resolveURL() for a base URL is the way to go I think. That sounds good to me. In general I think it would be great if there were standard APIs for URI/IRI construction, parsing and resolution... Yes, that sounds pretty good to me too. This has annoyed me for a while too. I'll write up a spec. Adam
Re: [XHR] Redirects
On Wed, Sep 15, 2010 at 3:07 AM, Julian Reschke julian.resc...@gmx.dewrote: On 15.09.2010 11:56, Boris Zbarsky wrote: On 9/15/10 2:47 AM, Boris Zbarsky wrote: So it's possible that the original behavior was just an oversight that then got copied. Someone with access to a browser version control system from before 1998 would need to look to make sure... It's also possible that no UA implementor was willing to implement the MUST NOT requirements below: 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. and 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. (RFC 2616 sections 10.3.2 and 10.3.3). How do you expect this to work in the XHR context? Is user for purposes of those two clauses the script that triggered the XHR, or the person actually represented by the user-agent (browser, say) in question? Then again, I guess they already ignore that MUST NOT clause for 307 redirects... So maybe they would just do the same thing here. Gotta love specs that really can't be implemented as written in sane ways. For XHR I'd argue that once the caller requests control over redirects, he's responsible to do it right. With respect to 2616 and the text you quoted above: the WG is aware of this problem, see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238. Best regards, Julian Adding a .followRedirect method means that developers can choose to use it or not. If they want to manually construct the redirected request, then they can do so using a new XHR object. However, if the use case is only auditing redirects, then being able to call .followRedirect on the existing XHR is quite convenient and minimizes the chances of making some common mistakes. -Darin
Re: [XHR] Redirects
On 16.09.2010 09:39, Darin Fisher wrote: ... Adding a .followRedirect method means that developers can choose to use it or not. If they want to manually construct the redirected request, then they can do so using a new XHR object. However, if the use case is only auditing redirects, then being able to call .followRedirect on the existing XHR is quite convenient and minimizes the chances of making some common mistakes. ... If using followRedirect() is easy, but manually following it is hard, people might choose the wrong approach just because it's easier. I think that obtaining the resolved Location for the redirect is the most tricky part, and we should come up with a solution where that is also available for people who do not want the default browser behavior. Best regards, Julian
Re: [XHR] Redirects
On Wed, Sep 15, 2010 at 2:56 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/15/10 2:47 AM, Boris Zbarsky wrote: So it's possible that the original behavior was just an oversight that then got copied. Someone with access to a browser version control system from before 1998 would need to look to make sure... It's also possible that no UA implementor was willing to implement the MUST NOT requirements below: 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. and 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. (RFC 2616 sections 10.3.2 and 10.3.3). How do you expect this to work in the XHR context? Is user for purposes of those two clauses the script that triggered the XHR, or the person actually represented by the user-agent (browser, say) in question? Then again, I guess they already ignore that MUST NOT clause for 307 redirects... So maybe they would just do the same thing here. Gotta love specs that really can't be implemented as written in sane ways. There's an open issue in the HTTPbis WG to remove that nonsense: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238 If you're interested in this topic, I'd encourage you to share your perspective with the httpbis working group. Adam
Re: [XHR] Redirects
On 9/16/10 12:51 AM, Adam Barth wrote: If you're interested in this topic, I'd encourage you to share your perspective with the httpbis working group. I'm not sure there's anything else to share, actually. Sounds like things are well in hand here. -Boris
Re: [XHR] Redirects
On Thu, 16 Sep 2010 09:50:41 +0200, Julian Reschke julian.resc...@gmx.de wrote: If using followRedirect() is easy, but manually following it is hard, people might choose the wrong approach just because it's easier. Well, what is wrong and what is right is still an open issue in the HTTP WG. I think that obtaining the resolved Location for the redirect is the most tricky part, and we should come up with a solution where that is also available for people who do not want the default browser behavior. I don't really like special casing the Location header here. It seems we are ending up with two additional members for dealing with redirects. I do not want another one. There are other headers where resolving a URL might be needed. Adding a parameter to navigator.resolveURL() for a base URL is the way to go I think. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On 16.09.2010 11:32, Anne van Kesteren wrote: On Thu, 16 Sep 2010 09:50:41 +0200, Julian Reschke julian.resc...@gmx.de wrote: If using followRedirect() is easy, but manually following it is hard, people might choose the wrong approach just because it's easier. Well, what is wrong and what is right is still an open issue in the HTTP WG. Yes, that's http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160. I note that there are servers out there that expect method name preservation upon 301/302 (such as Apache/moddav), and that there are clients out there that do this. I don't believe that we're going to make these cases non-compliant; maximally, we could state the special situation for POST (and just that, not all methods). I think that obtaining the resolved Location for the redirect is the most tricky part, and we should come up with a solution where that is also available for people who do not want the default browser behavior. I don't really like special casing the Location header here. It seems we are ending up with two additional members for dealing with redirects. I do not want another one. There are other headers where resolving a URL might be needed. Adding a parameter to navigator.resolveURL() for a base URL is the way to go I think. That sounds good to me. In general I think it would be great if there were standard APIs for URI/IRI construction, parsing and resolution... Best regards, Julian
Re: [XHR] Redirects
On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke julian.resc...@gmx.dewrote: I think that obtaining the resolved Location for the redirect is the most tricky part, and we should come up with a solution where that is also available for people who do not want the default browser behavior. I don't really like special casing the Location header here. It seems we are ending up with two additional members for dealing with redirects. I do not want another one. There are other headers where resolving a URL might be needed. Adding a parameter to navigator.resolveURL() for a base URL is the way to go I think. That sounds good to me. In general I think it would be great if there were standard APIs for URI/IRI construction, parsing and resolution... Yes, that sounds pretty good to me too. -Darin
Re: [XHR] Redirects
On 14.09.2010 18:52, Darin Fisher wrote: ... That's a good point. Note, resolving the Location header is only one of the issues. Another is knowing what HTTP method to use in response to a redirect. ... Always the same as for the original request, except for 303 :-).
Re: [XHR] Redirects
On 9/15/10 12:13 AM, Julian Reschke wrote: On 14.09.2010 18:52, Darin Fisher wrote: ... That's a good point. Note, resolving the Location header is only one of the issues. Another is knowing what HTTP method to use in response to a redirect. ... Always the same as for the original request, except for 303 :-). Can I assume the smily face implies that you know that in fact that's not what browsers do? ;) -Boris
Re: [XHR] Redirects
On 15.09.2010 09:58, Boris Zbarsky wrote: On 9/15/10 12:13 AM, Julian Reschke wrote: On 14.09.2010 18:52, Darin Fisher wrote: ... That's a good point. Note, resolving the Location header is only one of the issues. Another is knowing what HTTP method to use in response to a redirect. ... Always the same as for the original request, except for 303 :-). Can I assume the smily face implies that you know that in fact that's not what browsers do? ;) Yes. However, I was only 50% joking. Are we sure that XHR should behave the same? Best regards, Julian
Re: [XHR] Redirects
On 9/15/10 1:10 AM, Julian Reschke wrote: Yes. However, I was only 50% joking. Are we sure that XHR should behave the same? Why should it behave differently from every single other HTTP request the browser makes? That seems like adding complexity for the sake of complexity... -Boris
Re: [XHR] Redirects
On 15.09.2010 10:16, Boris Zbarsky wrote: On 9/15/10 1:10 AM, Julian Reschke wrote: Yes. However, I was only 50% joking. Are we sure that XHR should behave the same? Why should it behave differently from every single other HTTP request the browser makes? That seems like adding complexity for the sake of complexity... What browsers do today is a bug per spec. Use cases for XHR are not identical to surfing web pages. There are protocols/implementations that expect method names to be preserved for 301/302 (*), and an XHR2 with sane redirect handling should at least make it possible to talk to these servers. Best regards, Julian (*) For instance, when Apache/mod_dav 302-redirects a PROPFIND request, the expectation *indeed* is that the redirect request is a PROPFIND.
Re: [XHR] Redirects
On 9/15/10 1:37 AM, Julian Reschke wrote: What browsers do today is a bug per spec. Well, yes, but they implemented it that way as a specific workaround for broken servers, no? Use cases for XHR are not identical to surfing web pages. There are protocols/implementations that expect method names to be preserved for 301/302 (*), and an XHR2 with sane redirect handling should at least make it possible to talk to these servers. OK, I almost buy this argument. I feel that we should require opt-in to this behavior difference, though, not do it by default. -Boris
Re: [XHR] Redirects
On 9/15/10 2:40 AM, Julian Reschke wrote: Well, yes, but they implemented it that way as a specific workaround for broken servers, no? I'm not sure about that. Hmm, fair. I just looked up the history of this code in Gecko, and the best I can give you is https://bugzilla.mozilla.org/show_bug.cgi?id=48202#c6 and https://bugzilla.mozilla.org/show_bug.cgi?id=48202#c30 So it's possible that the original behavior was just an oversight that then got copied. Someone with access to a browser version control system from before 1998 would need to look to make sure... -Boris
Re: [XHR] Redirects
On 9/15/10 2:47 AM, Boris Zbarsky wrote: So it's possible that the original behavior was just an oversight that then got copied. Someone with access to a browser version control system from before 1998 would need to look to make sure... It's also possible that no UA implementor was willing to implement the MUST NOT requirements below: 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. and 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. (RFC 2616 sections 10.3.2 and 10.3.3). How do you expect this to work in the XHR context? Is user for purposes of those two clauses the script that triggered the XHR, or the person actually represented by the user-agent (browser, say) in question? Then again, I guess they already ignore that MUST NOT clause for 307 redirects... So maybe they would just do the same thing here. Gotta love specs that really can't be implemented as written in sane ways. -Boris
Re: [XHR] Redirects
On 15.09.2010 11:56, Boris Zbarsky wrote: On 9/15/10 2:47 AM, Boris Zbarsky wrote: So it's possible that the original behavior was just an oversight that then got copied. Someone with access to a browser version control system from before 1998 would need to look to make sure... It's also possible that no UA implementor was willing to implement the MUST NOT requirements below: 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. and 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. (RFC 2616 sections 10.3.2 and 10.3.3). How do you expect this to work in the XHR context? Is user for purposes of those two clauses the script that triggered the XHR, or the person actually represented by the user-agent (browser, say) in question? Then again, I guess they already ignore that MUST NOT clause for 307 redirects... So maybe they would just do the same thing here. Gotta love specs that really can't be implemented as written in sane ways. For XHR I'd argue that once the caller requests control over redirects, he's responsible to do it right. With respect to 2616 and the text you quoted above: the WG is aware of this problem, see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238. Best regards, Julian
Re: [XHR] Redirects
On Mon, Sep 13, 2010 at 8:51 AM, James Leigh james-nos...@leighnet.cawrote: On Wed, 2010-09-01 at 01:03 -0700, Darin Fisher wrote: I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. -Darin I want to point out that resolving the Location header is not specific to 3XX responses. A 201 (Created) response also includes a Location header that may need to be resolved. If the problem of providing a way to resolve redirect is addressed it might be good to also address the problem of resolving 201 locations as well. One suggestion might be to provide a getResponseLocation() that returns the resolved Location header. James That's a good point. Note, resolving the Location header is only one of the issues. Another is knowing what HTTP method to use in response to a redirect. -Darin
Re: [XHR] Redirects
On Mon, Sep 13, 2010 at 7:35 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher da...@chromium.org wrote: On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren ann...@opera.com wrote: That seems like the current design, except we currently do not have that additional method. I would like to keep it out until it is more clear this is a real problem. It would add quite a bit of complexity whereas just having this is fairly straightforward. The problems I've raised here are real problems that I've observed while building HTTP implementations for Mozilla and Chromium. It is easy for good coders to make these kinds of mistakes. I did not mean to downplay the problems you were raising. Do you think we should have a method like openPreserveState() that unlike open() does not reset a bunch of information? So to handle a redirect you would do openPreserveState(); send(); after the initial request if status is one of 301/302/303/307. (You might have to do some more.) That's a very interesting idea. Maybe it should be more specific, like openRedirectedLocation? That said, if one still has to call .send() afterwards, then we are still leaving it up to the caller to pass the right value to .send(). They have to know when the method is being changed from POST to GET and take appropriate action. That is a bit unfortunate. Maybe .send() and .openPreserveState() could just be combined into a single .followRedirect() method? Do you think I should comment out the followRedirects feature for now? At until we address the problem of how to follow it easily? I don't have strong opinions about that. It is up to you. I think it is OK to iterate :) -Darin -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Tue, 2010-09-14 at 09:55 -0700, Darin Fisher wrote: On Mon, Sep 13, 2010 at 7:35 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher da...@chromium.org wrote: On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren ann...@opera.com wrote: That seems like the current design, except we currently do not have that additional method. I would like to keep it out until it is more clear this is a real problem. It would add quite a bit of complexity whereas just having this is fairly straightforward. The problems I've raised here are real problems that I've observed while building HTTP implementations for Mozilla and Chromium. It is easy for good coders to make these kinds of mistakes. I did not mean to downplay the problems you were raising. Do you think we should have a method like openPreserveState() that unlike open() does not reset a bunch of information? So to handle a redirect you would do openPreserveState(); send(); after the initial request if status is one of 301/302/303/307. (You might have to do some more.) That's a very interesting idea. Maybe it should be more specific, like openRedirectedLocation? That said, if one still has to call .send() afterwards, then we are still leaving it up to the caller to pass the right value to .send(). They have to know when the method is being changed from POST to GET and take appropriate action. That is a bit unfortunate. Maybe .send() and .openPreserveState() could just be combined into a single .followRedirect() method? A challenge with having these methods combined is that it prevents the caller from changing (or preserving) the request header between redirects (Mozilla, for example, resets all its headers following a redirect). By keeping them separate the caller can reinstate non-standard (or standard) headers between redirects as necessary. Thanks, James
Re: [XHR] Redirects
On Tue, 14 Sep 2010 19:22:30 +0200, James Leigh james-nos...@leighnet.ca wrote: A challenge with having these methods combined is that it prevents the caller from changing (or preserving) the request header between redirects (Mozilla, for example, resets all its headers following a redirect). By keeping them separate the caller can reinstate non-standard (or standard) headers between redirects as necessary. Well, that is a bug that needs to be fixed. We do not introduce new features to work around bugs. It is covered by the XMLHttpRequest test suite: http://tc.labs.opera.com/apis/XMLHttpRequest/send-redirect.htm -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Thu, 02 Sep 2010 20:09:53 +0200, Darin Fisher da...@chromium.org wrote: One more question: suppose the author requests not to follow redirects. Should the .responseText property provide the response body sent with the redirect? Is there a use case for exposing the response body of a redirect page? (I ask because in Chromium, the cache does not store response bodies for cached redirects. IIRC, Mozilla's cache is similar.) When there is no Location header this scenario works fine: http://tc.labs.opera.com/apis/XMLHttpRequest/send-redirect-no-location.htm I would expect there to be a response entity body, yes. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher da...@chromium.org wrote: On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren ann...@opera.com wrote: That seems like the current design, except we currently do not have that additional method. I would like to keep it out until it is more clear this is a real problem. It would add quite a bit of complexity whereas just having this is fairly straightforward. The problems I've raised here are real problems that I've observed while building HTTP implementations for Mozilla and Chromium. It is easy for good coders to make these kinds of mistakes. I did not mean to downplay the problems you were raising. Do you think we should have a method like openPreserveState() that unlike open() does not reset a bunch of information? So to handle a redirect you would do openPreserveState(); send(); after the initial request if status is one of 301/302/303/307. (You might have to do some more.) Do you think I should comment out the followRedirects feature for now? At until we address the problem of how to follow it easily? -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Wed, 2010-09-01 at 01:03 -0700, Darin Fisher wrote: I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. -Darin I want to point out that resolving the Location header is not specific to 3XX responses. A 201 (Created) response also includes a Location header that may need to be resolved. If the problem of providing a way to resolve redirect is addressed it might be good to also address the problem of resolving 201 locations as well. One suggestion might be to provide a getResponseLocation() that returns the resolved Location header. James
Re: [XHR] Redirects
On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher da...@chromium.org wrote: On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren ann...@opera.com wrote: This does not work for synchronous requests in a worker. Hmm, good point. An alternative design might be a flag that causes .send() to complete once a redirect response is received, but then also provide a method on the XHR object to tell it to now follow the redirect. This model would work for both synchronous as well as asynchronous. That seems like the current design, except we currently do not have that additional method. I would like to keep it out until it is more clear this is a real problem. It would add quite a bit of complexity whereas just having this is fairly straightforward. One more question: suppose the author requests not to follow redirects. Should the .responseText property provide the response body sent with the redirect? Is there a use case for exposing the response body of a redirect page? (I ask because in Chromium, the cache does not store response bodies for cached redirects. IIRC, Mozilla's cache is similar.) -Darin I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. Yeah, I thought of that. There's location.resolveURL(), but it does not take a base URL at the moment. We could add that. Though note that relative URLs are forbidden in theory. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Wed, 01 Sep 2010 00:46:41 +0200, João Eiras joao.ei...@gmail.com wrote: Thank you. But there is one thing missing: the final url in case of a redirect chain. Currently that is not possible to guess for non xml requests or HEAD requests. My use case was about doing a HEAD and reading the Location header to know if was going to be redirected. Now I could set followRedirects to false and read it, but for cases where the redirection chain is followed, then new url is not available. Something like finalUrl which when readyState is = 1 it would have the value passed to open() and after, when the value is = 2 (headers received) it would have the value of the final url. That use case is addressed by implementing redirecting yourself. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Tue, 31 Aug 2010 22:51:19 +0200, Darin Fisher da...@chromium.org wrote: If instead, we had an API for auditing redirects (perhaps an onredirect event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Otherwise, the redirect would be processed normally. The result being that application authors would be guided away from following redirects manually, and hence they would avoid the problems I've described above. This does not work for synchronous requests in a worker. If we are okay with that it seems an acceptable alternative. However, redirects are processed before the object reaches HEADERS_RECEIVED (as otherwise it would reach that several times) so HTTP headers et cetera are not available yet. Given that, and given that you want that information, you would always invoke preventDefault(), defeating the purpose of having an event. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren ann...@opera.comwrote: On Tue, 31 Aug 2010 22:51:19 +0200, Darin Fisher da...@chromium.org wrote: If instead, we had an API for auditing redirects (perhaps an onredirect event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Otherwise, the redirect would be processed normally. The result being that application authors would be guided away from following redirects manually, and hence they would avoid the problems I've described above. This does not work for synchronous requests in a worker. Hmm, good point. An alternative design might be a flag that causes .send() to complete once a redirect response is received, but then also provide a method on the XHR object to tell it to now follow the redirect. This model would work for both synchronous as well as asynchronous. If we are okay with that it seems an acceptable alternative. However, redirects are processed before the object reaches HEADERS_RECEIVED (as otherwise it would reach that several times) so HTTP headers et cetera are not available yet. Given that, and given that you want that information, you would always invoke preventDefault(), defeating the purpose of having an event. It does seem like you'd want to see the headers corresponding to the redirect. I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. -Darin
Re: [XHR] Redirects
On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher da...@chromium.org wrote: On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren ann...@opera.comwrote: This does not work for synchronous requests in a worker. Hmm, good point. An alternative design might be a flag that causes .send() to complete once a redirect response is received, but then also provide a method on the XHR object to tell it to now follow the redirect. This model would work for both synchronous as well as asynchronous. That seems like the current design, except we currently do not have that additional method. I would like to keep it out until it is more clear this is a real problem. It would add quite a bit of complexity whereas just having this is fairly straightforward. I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. Yeah, I thought of that. There's location.resolveURL(), but it does not take a base URL at the moment. We could add that. Though note that relative URLs are forbidden in theory. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On 01.09.2010 10:16, Anne van Kesteren wrote: ... I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. Yeah, I thought of that. There's location.resolveURL(), but it does not take a base URL at the moment. We could add that. Though note that relative URLs are forbidden in theory. ... They are in RFC 2616, but not in HTTPbis (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-11.html#rfc.section.9.4). Best regards, Julian
Re: [XHR] Redirects
On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher da...@chromium.org wrote: On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren ann...@opera.com wrote: This does not work for synchronous requests in a worker. Hmm, good point. An alternative design might be a flag that causes .send() to complete once a redirect response is received, but then also provide a method on the XHR object to tell it to now follow the redirect. This model would work for both synchronous as well as asynchronous. That seems like the current design, except we currently do not have that additional method. I would like to keep it out until it is more clear this is a real problem. It would add quite a bit of complexity whereas just having this is fairly straightforward. The problems I've raised here are real problems that I've observed while building HTTP implementations for Mozilla and Chromium. It is easy for good coders to make these kinds of mistakes. -Darin I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. Yeah, I thought of that. There's location.resolveURL(), but it does not take a base URL at the moment. We could add that. Though note that relative URLs are forbidden in theory. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Wed, Sep 1, 2010 at 5:19 AM, Julian Reschke julian.resc...@gmx.dewrote: On 01.09.2010 10:16, Anne van Kesteren wrote: ... I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. Yeah, I thought of that. There's location.resolveURL(), but it does not take a base URL at the moment. We could add that. Though note that relative URLs are forbidden in theory. ... They are in RFC 2616, but not in HTTPbis ( http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-11.html#rfc.section.9.4 ). Best regards, Julian What does it mean for them to not be part of HTTPbis? Relative URLs in Location headers are not uncommon. -Darin
Re: [XHR] Redirects
* Darin Fisher wrote: Though note that relative URLs are forbidden in theory. They are in RFC 2616, but not in HTTPbis ... What does it mean for them to not be part of HTTPbis? Relative URLs in Location headers are not uncommon. You missed the double negative. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [XHR] Redirects
On 02.09.2010 00:00, Darin Fisher wrote: On Wed, Sep 1, 2010 at 5:19 AM, Julian Reschke julian.resc...@gmx.de mailto:julian.resc...@gmx.de wrote: On 01.09.2010 10:16, Anne van Kesteren wrote: ... I thought of another reason to want the original XHR object to be responsible for following the redirect: the value of a Location header may be a relative URL. It would be nice if application authors did not have to take care of resolving that manually. (In the case of a cross-origin request, the relative URL should be resolved relative to the URL that was redirected instead of against the Document.) This seems like something that could be easy to mess up. Yeah, I thought of that. There's location.resolveURL(), but it does not take a base URL at the moment. We could add that. Though note that relative URLs are forbidden in theory. ... They are in RFC 2616, but not in HTTPbis (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-11.html#rfc.section.9.4). Best regards, Julian What does it mean for them to not be part of HTTPbis? Relative URLs in Location headers are not uncommon. Clarifying: they are *forbidden* in RFC 2616 (*), but not in HTTPbis (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics11.html#rfc.section.9.4), so HTTPbis *allows* them now. BR, Julian (*) the ABNF doesn't allow them.
Re: [XHR] Redirects
On Fri, Aug 27, 2010 at 5:50 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras joao.ei...@gmail.com wrote: Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill. I went for a boolean followRedirects attribute as that gives sufficient low-level control that people can implement whatever behavior they want on top of that. (Including every use case mentioned in this thread.) This is an XMLHttpRequest Level 2 feature now: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ So the idea is that you would have to manually create the redirect request using a new XHR if you wanted to manually follow the redirect? One risk with that is that it is easy to construct the redirect request improperly. There's the classic example of what happens when you issue a POST request and it results in a redirect. 303 and 307 had to be invented because some browsers implemented 302 incorrectly. Maybe there should be a way to create a new XHR from the existing XHR that is already configured to follow the redirect? I'm not sure how to make this less awkward... -Darin -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Tue, 31 Aug 2010 19:04:08 +0200, Darin Fisher da...@chromium.org wrote: So the idea is that you would have to manually create the redirect request using a new XHR if you wanted to manually follow the redirect? Yeah, or you could reset the existing object using open(). One risk with that is that it is easy to construct the redirect request improperly. There's the classic example of what happens when you issue a POST request and it results in a redirect. 303 and 307 had to be invented because some browsers implemented 302 incorrectly. Yeah, though I think that the people that implement redirects manually have put some thought in the matter. Maybe that is naive, though on the other hand if people do it wrong it does not matter much either. Maybe there should be a way to create a new XHR from the existing XHR that is already configured to follow the redirect? I'm not sure how to make this less awkward... If this is actually common and people start using this a lot and ask this question here that would be the point where we should start thinking about making this less awkward. For now libraries and developers with lots of time have all the hooks they need. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Tue, Aug 31, 2010 at 1:16 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 31 Aug 2010 19:04:08 +0200, Darin Fisher da...@chromium.org wrote: So the idea is that you would have to manually create the redirect request using a new XHR if you wanted to manually follow the redirect? Yeah, or you could reset the existing object using open(). One risk with that is that it is easy to construct the redirect request improperly. There's the classic example of what happens when you issue a POST request and it results in a redirect. 303 and 307 had to be invented because some browsers implemented 302 incorrectly. Yeah, though I think that the people that implement redirects manually have put some thought in the matter. Maybe that is naive, though on the other hand if people do it wrong it does not matter much either. Maybe there should be a way to create a new XHR from the existing XHR that is already configured to follow the redirect? I'm not sure how to make this less awkward... If this is actually common and people start using this a lot and ask this question here that would be the point where we should start thinking about making this less awkward. For now libraries and developers with lots of time have all the hooks they need. Hmm, that's a pretty good argument. Another issue that concerns me is redirect loops. The proposed API gives us know way to know that the application is following a redirect chain, which means that we have little way to know if the application is following an endless redirect chain. The classical example is a server that redirects back to the same URL with a Set-Cookie header, expecting the next request to have a corresponding Cookie header. If the Cookie header is not added, then the redirect is issued again. Most browsers detect this after N iterations, and then give up. Of course, this situation only occurs if the user has disabled cookies in the User Agent. I worry that a case like this will almost never be tested by application developers, and hence, users who like to disable some cookies will be unable to use the internet. (I realize that the internet is mostly broken already if you disable cookies, but there are some variations of cookie blocking that sort of work.) A User Agent could try to implement a heuristic to catch certain flavors of redirect chains, by observing the XHR requests made by an application. But, it seems like it would be fairly difficult to avoid false positives. If instead, we had an API for auditing redirects (perhaps an onredirect event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Otherwise, the redirect would be processed normally. The result being that application authors would be guided away from following redirects manually, and hence they would avoid the problems I've described above. -Darin
Re: [XHR] Redirects
On , Anne van Kesteren ann...@opera.com wrote: On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras joao.ei...@gmail.com wrote: Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill. I went for a boolean followRedirects attribute as that gives sufficient low-level control that people can implement whatever behavior they want on top of that. (Including every use case mentioned in this thread.) This is an XMLHttpRequest Level 2 feature now: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thank you. But there is one thing missing: the final url in case of a redirect chain. Currently that is not possible to guess for non xml requests or HEAD requests. My use case was about doing a HEAD and reading the Location header to know if was going to be redirected. Now I could set followRedirects to false and read it, but for cases where the redirection chain is followed, then new url is not available. Something like finalUrl which when readyState is = 1 it would have the value passed to open() and after, when the value is = 2 (headers received) it would have the value of the final url. Another issue that concerns me is redirect loops. The proposed API gives us know way to know that the application is following a redirect chain, which means that we have little way to know if the application is following an endless redirect chain. Following redirects is the default behavior, and user agents abort after N iterations regardless of whether it's XHR or a regular request. The new followRedirects feature is for opting into disabling it. If instead, we had an API for auditing redirects (perhaps an onredirect event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Quite an edge case, but setting followRedirects to false and then creating individual XHRs for each 302 response explicitly should work.
Re: [XHR] Redirects
On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras joao.ei...@gmail.com wrote: Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill. I went for a boolean followRedirects attribute as that gives sufficient low-level control that people can implement whatever behavior they want on top of that. (Including every use case mentioned in this thread.) This is an XMLHttpRequest Level 2 feature now: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Fri, 2010-08-13 at 00:03 +0200, Anne van Kesteren wrote: On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras joao.ei...@gmail.com wrote: b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? We might add something like this at some point (probably by way of a followRedirects boolean) but so far the use cases have not been really strong so it has not been given much priority. A boolean flag would be fine for my use case, which is a 303 following a POST. The POST request is sent over XHR, but the target location of the redirect is an HTML document that should be shown to the user in the browser window. I need to have access to the target location in JavaScript to direct the browser window to that location. James
Re: [XHR] Redirects
On 13.08.2010 00:03, Anne van Kesteren wrote: ... For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? ... Some that come to mind quickly: - Depending on the redirect status, you may want to stop accessing the original URI. - Depending on the method, you may want to confirm with the user whether automatically following the redirect is ok. - You may want to display the actual URI somewhere in the UI. Best regards, Julian
Re: [XHR] Redirects
Julian Reschke wrote: On 13.08.2010 00:03, Anne van Kesteren wrote: ... For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? ... Some that come to mind quickly: - Depending on the redirect status, you may want to stop accessing the original URI. - Depending on the method, you may want to confirm with the user whether automatically following the redirect is ok. - You may want to display the actual URI somewhere in the UI. and - You may need to use the URI to perform PUT/DELETE operations - You may need the URI to resolve relative references within response headers or the message-body
[XHR] Redirects
Hi ! a) If a XHR follows a redirection chain, does the API provide a way to retrieve the final url? b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj.
Re: [XHR] Redirects
On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras joao.ei...@gmail.com wrote: Hi ! a) If a XHR follows a redirection chain, does the API provide a way to retrieve the final url? Apart from document.responseXML.URL I do not think so. And I'm not sure if document.responseXML.URL is supposed to work. b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? We might add something like this at some point (probably by way of a followRedirects boolean) but so far the use cases have not been really strong so it has not been given much priority. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On , Anne van Kesteren ann...@opera.com wrote: On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras joao.ei...@gmail.com wrote: Hi ! a) If a XHR follows a redirection chain, does the API provide a way to retrieve the final url? Apart from document.responseXML.URL I do not think so. And I'm not sure if document.responseXML.URL is supposed to work. It might not be an xml file, hence resonseXML is not defined and that's no good. b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? We might add something like this at some point (probably by way of a followRedirects boolean) but so far the use cases have not been really strong so it has not been given much priority. In my specific case, I had an url to a media file which I needed to feed to a plugin. But the plugin did not handle redirects. So I needed to do a HEAD request, and check if it returned 302 and read the Location header. But due to the implicit redirecting handling, and no way to access the final url, that was impossible. So, two problems in one. Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill.
Re: [XHR] Redirects
On Thu, Aug 12, 2010 at 3:03 PM, Anne van Kesteren ann...@opera.com wrote: On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras joao.ei...@gmail.com wrote: Hi ! a) If a XHR follows a redirection chain, does the API provide a way to retrieve the final url? Apart from document.responseXML.URL I do not think so. And I'm not sure if document.responseXML.URL is supposed to work. I've run into this limitation before as well. Unfortunately, responseXML.URL doesn't get populated if the response isn't XML. The use case is I want to know where the response came from (as opposed to where the first request in the redirect chain went). :) Adam
