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
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
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
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
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
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
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
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
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
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 :-).
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,
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.
...
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
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
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
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
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
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
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
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
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
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).
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
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
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
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,
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
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
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
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
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
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,
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
* 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 ·
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
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
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
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?
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
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
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
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
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
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
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
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
46 matches
Mail list logo
