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

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Aug 2009 16:34:25 +1000

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.

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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 25 Aug 2009 09:54:15 +0200

On Fri, 21 Aug 2009 08:34:25 +0200, Mark Nottingham <[email-masked]> wrote:
> 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/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Aug 2009 10:08:55 +0200

Anne van Kesteren wrote:
> ...

It will be invalid.

 > ...

BR, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 25 Aug 2009 10:15:43 +0200

> It will be invalid.

As far as I can tell the draft does not define what it means for something to be invalid. Even if it did, presumably that still leaves my remaining two points.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Aug 2009 10:25:27 +0200

> As far as I can tell the draft does not define what it means for something to be invalid. Even if it did, presumably that still leaves my remaining two points.

Invalid means invalid. The outcome is undefined.

BR, Julian

---

From: Sam Johnston <[email-masked]>
Date: Tue, 25 Aug 2009 10:39:30 +0200

On Tue, Aug 25, 2009 at 10:25 AM, Julian Reschke <[email-masked]>wrote:

>> As far as I can tell the draft does not define what it means for something
>> to be invalid. Even if it did, presumably that still leaves my remaining two
>> points.
>>
> > ...
>

In my mind a delimiter (e.g. colons, commas, etc.) must only appear once but
whitespace can appear repetitively, even with a mix - e.g. trailing space,
newline and tab where the list is long.

In terms of being conservative with what you send and liberal in what you
receive it would arguably be safest to allow for any combination of
whitespace characters but recommend that servers only ever use a single
space.

Compliance with current practices seems sensible too - declaring existing
working implementations invalid is rarely sensible.

Sam

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Aug 2009 11:48:47 +0200

Anne van Kesteren wrote:
> On Tue, 25 Aug 2009 10:25:27 +0200, Julian Reschke <[email-masked]> wrote:
> Disagreed, this is e.g. not the case with CSS.

Anne, it *is* the case unless a spec states how to process it.

BR, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 25 Aug 2009 11:33:59 +0200