Subject: Re: #160: Redirects and non-GET methods

From: Julian Reschke <[email-masked]>
Date: Thu, 01 Sep 2011 11:33:45 +0200

On 2011-08-31 16:30, Julian Reschke wrote:
> ...
> See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>; feedback
> appreciated.
> ...

Applied with minor fixes in 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1428>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 01 Sep 2011 12:48:03 +0200

On 2011-09-01 03:33, Mark Nottingham wrote:
>
> On 01/09/2011, at 11:31 AM, Roy T. Fielding wrote:
>
>> On Aug 31, 2011, at 5:21 PM, Mark Nottingham wrote:
>>
>>> Is this going to confuse new readers?
>>
>> New readers don't know what retrieval means?
>
> Considering all of the issues we've had with other redirects and methods, I'm wary of making it more abstract...
>
>
>>> Can we clarify with something like
>>>
>>>
>>> """
>>> ...perform a retrieval request (i.e., a GET, unless the original method was HEAD)...
>>> """
>>
>> The problem is that the redirect might be to any URI,
>> and thus the next request might not be HTTP.
>
>
> Ah. How about
>
> "... perform a retrieval request (in HTTP, a GET, unless the original method was HEAD)..."
> ...

OK, let's do that: 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1429>, although it 
would have been nice not to have to be that specific...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 01 Sep 2011 12:51:47 +0200

Hi there,

the following issues remain:

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238> - this is about 
the user agent interaction requirement

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295> - fragment handling

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/312> - raised 
recently so we don't forget about it: if servers can not rely on POST 
not being rewritten to GET, should there be an equivalent of 307 for 
permanent redirects, or a description how to affect the "permanence" of 
a 307?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Sep 2011 11:06:34 +1000

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/295> - fragment handling

We discussed this a little while back, and the only pushback was from you as to whether it was appropriate for HTTPbis to go here.

We have feedback from Eric and Adam that they'd like to see us do this.

I put forth the idea of going to the TAG about it earlier, but when we asked them about #43, they didn't seem to have any strong advice (see <http://www.w3.org/mid/[email-masked]>).

Speaking personally -- I think it would improve interop if we did this, and I think we should also consider reopening #43 to define the case where both have a fragment (since there appears to be emerging interop). 

Having HTTP define fragment combination (both in the single and dual cases) makes sense, because IME, client-side stacks handle HTTP redirects automatically, before the format-specific machinery ever gets to see the HTTP. Requiring -- or even allowing -- that this be format-specific opens up a huge can of worms in most implementations, and makes the Web a much more complex place.

What do others think?

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Sep 2011 10:34:14 +0200

On 2011-09-02 03:06, Mark Nottingham wrote:
> I put forth the idea of going to the TAG about it earlier, but when we asked them about #43, they didn't seem to have any strong advice (see<http://www.w3.org/mid/[email-masked]>).
>

Are you saying that these stacks actually handle fragments? Example?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Sep 2011 18:52:48 +1000

> Are you saying that these stacks actually handle fragments? Example?

No, I'm saying that many handle redirects, and re-engineering them to delegate fragment combination to format-specific handlers will be awkward.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Sep 2011 11:06:33 +0200

> No, I'm saying that many handle redirects, and re-engineering them to delegate fragment combination to format-specific handlers will be awkward.

I have trouble following :-)

If a stack does follow redirects but does not handle fragments (XHR for 
instance?), all it can do is to provide information about the "final" 
fragment to the user/caller. Is this what you have in mind?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Sep 2011 12:47:38 +0200

> Having HTTP define fragment combination (both in the single and dual cases) makes sense, because IME, client-side stacks handle HTTP redirects automatically, before the format-specific machinery ev…

I agree that having it format-specific makes the web more complex; but 
right now this is the case; for instance, fragment recombination works 
different for HTML and PDF, as far as I can tell.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 03 Sep 2011 14:26:58 +0200

On 2011-09-02 12:47, Julian Reschke wrote:
>> Having HTTP define fragment combination (both in the single and dual
>> cases) makes sense, because IME, client-side stacks handle HTTP
>> redirects automatically, before the format-specific machinery ever
>> gets to see the HTTP. Requiring -- or even allowing -- that this be
>> format-specific opens up a huge can of worms in most implementations,
>> and makes the Web a much more complex place.
>> ...
>

...expanding on this -- tested with FF and Reader plugin; accessing 
a.pdf#foo, getting redirected to b.pdf#bar yields b.pdf#foo in the 
address bar (I don't believe it's the plugin's fault).

Best regards, Julian