W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: [draft-nottingham-http-link-header-06] relation-types

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 25 Aug 2009 09:54:15 +0200
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Message-ID: <op.uy7j8pp264w2qv@annevk-t60>
On Fri, 21 Aug 2009 08:34:25 +0200, Mark Nottingham <mnot@mnot.net> wrote:
> On 25/07/2009, at 12:05 AM, Anne van Kesteren wrote:
>> I think multiple SP characters should be allowed between relation  
>> types. That makes it more consistent with other serializations.
>> I actually doubt existing implementations do it like the draft  
>> suggests. The tab character would probably work fine too and maybe  
>> something else I'm forgetting. Has this been tested?
>
> Existing implementations do it like the draft suggests, in that when  
> they use the Link header, they accept the specified form.
>
> FF3.5 allows both multiple spaces and tabs.
> Opera 10b3 only allows multiple spaces, doesn't recognise tabs.
> Safari and IE both appear to ignore the Link header.
>
> The safest thing to do is to leave it specified as a single space; all  
> implementations that support Link (remembering that it was first defined  
> this way in 2068) will be able to consume that.

Well, I do not think that is the safest thing at all from my perspective:

1. It is not clear to me what it means to recognize only a single space as consumer. What are the values for "foo{SP}{SP}bar"? Will that be "foo" and "{SP}bar"? Or "foo{SP}" and "bar"? Something else?

2. If producers are currently using multiple spaces both Firefox and Opera would break with these producers.

3. If producers are currently using tabs Opera would break with these producers and I'd be inclined to make us match Firefox rather than making us even more strict which would be compatible with exactly no implementation.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Tuesday, 25 August 2009 07:55:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT