Re: Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments)

FYI, tests online at:
Source at:

My take on this is that it's an area that's important for interoperability that is the responsibility of HTTP, but was omitted from the original specification. We can consider making a clarification here, and if it breaks an implementation or two, we can note that potential incompatibility (just as 2616 did in a few cases).


On 12/03/2010, at 4:52 AM, Jonas Sicking wrote:

> On Thu, Mar 11, 2010 at 9:28 AM, Julian Reschke <> wrote:
>> On 11.03.2010 18:22, Jonas Sicking wrote:
>>> On Thu, Mar 11, 2010 at 7:48 AM, Julian Reschke<>
>>>  wrote:
>>>> On 11.03.2010 16:38, Jonas Sicking wrote:
>>>>> On Thu, Mar 11, 2010 at 7:35 AM, Julian Reschke<>
>>>>>  wrote:
>>>>>> Should we recommend the behavior we see implemented (SHOULD? MUST?)?
>>>>>> Note
>>>>>> that this would make current implementations of Opera and Safari
>>>>>> non-compliant.
>>>>> Is there a reason to use SHOULD rather than MUST? If not I'd say use
>>>>> MUST.
>>>> Usually we don't add normative requirements on top of RFC 2616, unless
>>>> we're
>>>> clearly fixing a bug (which is not the case here), or are confident that
>>>> we're just writing down what everybody is doing anyway.
>>> Why? Isn't the point of a spec to encourage interoperable behavior?
>> It depends.
>> If there's no interop today, and the existing implementations are conforming
>> with respect to RFC 2616, we *usually* don't break them - there would need
>> to be very good reasons to do so, such as security related ones.
> I can't say that I agree with that reasoning. IMHO interoperability
> going forward is more important than not declaring currently
> conforming implementations non-conforming. If anyone gets really sad
> for loosing their conforming badge, I can send them some home made
> cookies ;)
> / Jonas

Mark Nottingham

Received on Saturday, 13 March 2010 00:14:32 UTC