Mark Nottingham | 1 Sep 02:21 2011
Picon

Re: #310, was: #160: Redirects and non-GET methods

Is this going to confuse new readers?

Can we clarify with something like

"""
...perform a retrieval request (i.e., a GET, unless the original method was HEAD)...
"""

?

On 31/08/2011, at 6:54 PM, Julian Reschke wrote:

> On 2011-08-08 10:10, Julian Reschke wrote:
>> On 2011-08-08 09:25, Mark Nottingham wrote:
>>> Yes; please go ahead and open one.
>>> ...
>> 
>> -> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/310>
> 
> Roy came up with a new intro for 303:
> 
>   The 303 status code indicates that the server is redirecting the
>   user agent to a different resource, as indicated by a URI in the
>   Location header field, that is intended to provide an indirect
>   response to the original request.  In order to satisfy the original
>   request, a user agent SHOULD perform a retrieval request using the
>   Location URI, which may itself be redirected further, and present
>   the eventual result as an answer to the original request.
>   Note that the new URI in the Location header field is not considered
>   equivalent to the effective request URI.
(Continue reading)

Roy T. Fielding | 1 Sep 03:31 2011

Re: #310, was: #160: Redirects and non-GET methods

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?

> 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.

....Roy

Mark Nottingham | 1 Sep 03:33 2011
Picon

Re: #310, was: #160: Redirects and non-GET methods


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)..."

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

Amos Jeffries | 1 Sep 06:02 2011
Picon

Re: #310, was: #160: Redirects and non-GET methods

 On Thu, 1 Sep 2011 11:33:47 +1000, 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)..."
>
(Continue reading)

Julian Reschke | 1 Sep 11:33 2011
Picon
Picon

Re: #160: Redirects and non-GET methods

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

Julian Reschke | 1 Sep 12:48 2011
Picon
Picon

Re: #310, was: #160: Redirects and non-GET methods

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: 
(Continue reading)

Julian Reschke | 1 Sep 12:51 2011
Picon
Picon

Remaining issues related to redirects

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

Julian Reschke | 1 Sep 19:44 2011
Picon
Picon

Re: #306: does etag value really use quoted-string

On 2011-08-30 13:35, Mark Nottingham wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/306>
>
> IIRC we checked various implementations and found that many don't handle ETags as a quoted-string;
therefore, the safe/sensible thing to do is to re-define ETag as a something else; i.e., something with
the same syntax, but without any special semantic for backslashes.
>
> We might also caution against including backslashes in them in prose, since it isn't interoperable.
>
> Thoughts / objections?

Sounds right to me.

Best regards, Julian

Julian Reschke | 1 Sep 19:56 2011
Picon
Picon

Re: #306: does etag value really use quoted-string

On 2011-08-30 13:35, Mark Nottingham wrote:
> ...
> We might also caution against including backslashes in them in prose, since it isn't interoperable.
> ...

Right now, the ABNF also allows

- OWS (optional whitespace)
- obs-text (octets >= 128)

Do we need to keep those in the grammar?

Best regards, Julian

Julian Reschke | 1 Sep 20:59 2011
Picon
Picon

Re: #306: does etag value really use quoted-string

On 2011-08-30 13:35, Mark Nottingham wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/306>
>
> IIRC we checked various implementations and found that many don't handle ETags as a quoted-string;
therefore, the safe/sensible thing to do is to re-define ETag as a something else; i.e., something with
the same syntax, but without any special semantic for backslashes.
>
> We might also caution against including backslashes in them in prose, since it isn't interoperable.
>
> Thoughts / objections?
>
> --
> Mark Nottingham   http://www.mnot.net/

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/306/306.diff>

The definition would then read:

2.3.  ETag

    The ETag header field provides the current entity-tag for the
    selected representation.  An entity-tag is an opaque validator for
    differentiating between multiple representations of the same
    resource, regardless of whether those multiple representations are
    due to resource state changes over time, content negotiation
    resulting in multiple representations being valid at the same time,
    or both.  An entity-tag consists of an opaque quoted string, possibly
    prefixed by a weakness indicator.

(Continue reading)


Gmane