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
On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras
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 th
On , Anne van Kesteren wrote:
On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras
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 sup
On Thu, Aug 12, 2010 at 3:03 PM, Anne van Kesteren wrote:
> On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras 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 n
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 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 Infi
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 somethin
On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras
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
On Fri, Aug 27, 2010 at 5:50 AM, Anne van Kesteren wrote:
> On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras
> 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 followRed
On Tue, 31 Aug 2010 19:04:08 +0200, Darin Fisher
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 eas
On Tue, Aug 31, 2010 at 1:16 PM, Anne van Kesteren wrote:
> On Tue, 31 Aug 2010 19:04:08 +0200, Darin Fisher
> 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
On , Anne van Kesteren wrote:
On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras
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 Wed, 01 Sep 2010 00:46:41 +0200, João Eiras
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 k
On Tue, 31 Aug 2010 22:51:19 +0200, Darin Fisher
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
On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren wrote:
> On Tue, 31 Aug 2010 22:51:19 +0200, Darin Fisher
> 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 t
On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher
wrote:
On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren
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 r
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 ma
On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren wrote:
> On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher
> wrote:
>
>> On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren > >wrote:
>>
>>> This does not work for synchronous requests in a worker.
>>>
>>
>> Hmm, good point. An alternative desig
On Wed, Sep 1, 2010 at 5:19 AM, Julian Reschke 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
* 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 · mail
On 02.09.2010 00:00, Darin Fisher wrote:
On Wed, Sep 1, 2010 at 5:19 AM, Julian Reschke 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
resp
On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren wrote:
> On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher
> wrote:
>
>> On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren > >wrote:
>>
>>> This does not work for synchronous requests in a worker.
>>>
>>
>> Hmm, good point. An alternative desig
On Thu, 02 Sep 2010 20:09:53 +0200, Darin Fisher
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 a
On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher
wrote:
On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren
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
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 r
On Mon, Sep 13, 2010 at 8:51 AM, James Leigh wrote:
> 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
On Mon, Sep 13, 2010 at 7:35 AM, Anne van Kesteren wrote:
> On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher
> wrote:
>
>> On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren
>> wrote:
>>
>>> That seems like the current design, except we currently do not have that
>>> additional method. I would l
On Tue, 2010-09-14 at 09:55 -0700, Darin Fisher wrote:
> On Mon, Sep 13, 2010 at 7:35 AM, Anne van Kesteren
> wrote:
> On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher
> wrote:
>
> On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren
> wrote:
On Tue, 14 Sep 2010 19:22:30 +0200, James Leigh
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 t
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, exc
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.
...
Alway
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 t
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 n
On 15.09.2010 10:44, Boris Zbarsky wrote:
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?
I'm not sure about that.
Use cases for XHR are not identical to surfing
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_bu
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 i
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 possi
On Wed, Sep 15, 2010 at 3:07 AM, Julian Reschke wrote:
> 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 syste
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 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 s
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
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 obta
On 16.09.2010 11:32, Anne van Kesteren wrote:
On Thu, 16 Sep 2010 09:50:41 +0200, Julian Reschke
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
On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke 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
On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher wrote:
> On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke
> 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 d
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 be
48 matches
Mail list logo