Re: httpRange-14 Change Proposal

On Sun, Mar 25, 2012 at 4:50 PM, Noah Mendelsohn <nrm@arcanedomain.com> wrote:
>
>
> On 3/25/2012 3:29 PM, Jeni Tennison wrote:
>>>
>>> I assume it's the most common case, but my reading of 303 is that it's
>>> intentionally pretty vague. I read it as: "you might find something useful
>>> over here -- feel free to do a GET and see what happens". In fact, I'm not
>>> sure it's even clear that 303 targets need to be http resources at all. Is
>>> it provably wrong, e.g., to do a 303 redirect to a mailto URI?
>>
>>
>> As Jonathan has written it, a 303 response or a Link: header with a
>> describedby relationship indicates that nominal representations from the
>> target of the link are nominal URI documentation carriers for the probe URI.
>> That's a bit stronger than "you might find something useful over there".
>
>
> Fair enough. I was referring to RFC 2616 definition of RFC 303, not the
> baseline from Jonathan. I'm not sure I understand Jonathan's wording well
> enough yet to comment reliably, but if it goes much beyond clarifying what's
> in RFC 2616 as to the semantics of 303, or illustrating particular usage
> patterns appropriate to metadata discovery, than I might have a problem with
> it too.

The baseline starts from HTTPbis, not 2616.

> At least for the moment, I'm reluctant to change the RFC 2616 definitions of
> status codes that are already deployed, except where clarification is
> helpful. I'm fine with explaining how they can be used in ways consistent
> with the exiting definitions to achieve metadata discovery, and I'm also OK
> with proposing new status codes, headers, etc.

I have confidence in HTTPbis. It is the wave of the future. :)

Jonathan

> Noah
>

Received on Sunday, 25 March 2012 21:15:33 UTC