headers
Mark Nottingham | 1 Sep 2011 02:21
Favicon
Gravatar

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)

Permalink | Reply | 4 comments |
headers
Roy T. Fielding | 1 Sep 2011 03:31
Favicon
Gravatar

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
Permalink | Reply | 3 comments |
headers
Mark Nottingham | 1 Sep 2011 03:33
Favicon
Gravatar

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/
Permalink | Reply | 2 comments |
headers
Amos Jeffries | 1 Sep 2011 06:02
Picon
Favicon

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)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 1 Sep 2011 11:33
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
Permalink | Reply | 10 comments |
headers
Julian Reschke | 1 Sep 2011 12:48
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)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 1 Sep 2011 12:51
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
Permalink | Reply | 6 comments |
headers
Julian Reschke | 1 Sep 2011 19:44
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
Permalink | Reply | 0 comments |
headers
Julian Reschke | 1 Sep 2011 19:56
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
Permalink | Reply | 0 comments |
headers
Julian Reschke | 1 Sep 2011 20:59
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)

Permalink | Reply | 8 comments |

Gmane