Re: [ISSUE-81, ACTION-13] Response Header Format


Hi Team,

I see Roys point that compliancy is often all-site or nothing.

I would like to come back to my earlier question: Which are
scenarios/usecases that are important and that require an individualized
response header?


Regards,
 Matthias

-original message-
Subject: Re: [ISSUE-81, ACTION-13] Response Header Format
From: "Roy T. Fielding" <fielding@gbiv.com>
Date: 2011/10/19 02:51

On Oct 14, 2011, at 2:40 PM, Kevin Smith wrote:

> I am still not convinced a return header is necessary, but if we decide
it is, as Tom mentioned in Action 13, it is important that our spec be very
extensible for possible future modifications.  The binary approach he
suggested (1 = Respect the DNT signal, 0 = Will not respect) is certainly
easy to extend.  If other responses are needed, you can easily add
additional codes.  If we wanted to add textual explanations as Peter (I
think) suggested in Boston, or URIs to definition documents as Roy
suggested, they could easily be appended to the header.
>
> However, one thing that a 0|1 response would make it difficult to do in
the future would be to group different types of responses such as defined
reasons why a site may or may not respect the DNT header.  If we think it
is likely that additional responses will be needed now or in the future, we
may want to follow something closer to the http response codes (ie 200s =
ok, 300s = redirect, 400s = bad request etc)

Speaking as an editor of the HTTP spec, I do not want to see
yet another three-digit response code in HTTP.  They are useful
for status codes because we expect to need the space and the code
is often visible to users.  A similar three-digit code was added
for cache warnings, and that was a horrible mistake.  Any discussion
about such codes leads to confusion with the status codes.

> For example,
>
> 100 = Will not respect DNT (same as currently suggested 0)
> 101 = Will not respect because I am a 1st party
> 102 = Will not respect because you have opted in to my tracking
> 103 = Allowed to track because it’s for research (possibly)
> 104 = Allowed to track because of exemption X
> …
>
> 200 = Will Respect DNT (same as currently suggested 1)
> 201 = Even though DNT was not turned on, you have an opt-out cookie
> 202 = I never track
> …
>
> 300 = I don’t know (could be the default, and probably means the same
thing as no response)
> 301 = Don’t know because I have never set up a web server before, I don’t
know what DNT means and I will never get enough hits for anyone to care
about what I do anyway.  (OK, we probably do not need a code for this –
just checking if you are still reading)
> …
>
> Then if a browser or plugin wanted to provide a more customized
experience to the user, it could use this additional information.  I am not
saying that we should take this approach now (or ever), but if we wanted to
start with the simple binary approach, perhaps we should start with codes
100=No, 200=Yes (or something similar), so that we leave our options open
in the future.
>
> Note: this is certainly not the only way to do it.  We could also go with
a 0|1 now, and then add a delimiter with a subcode (ie – 1:2 = You have
opted back in).  I just thought this may be a good grouping mechanism that
is easy to parse and process.

My intention is to initially spec the usual HTTP extensibility mechanism

( "0" / "1" ) *[ ";" token [ "=" ( token / quoted-string ) ]]

and state in the prose that recipients need only parse the first
character of the field-value if they do not support extensions.

Also, there is no deployed practice for a response header field,
so I do not plan on reusing the DNT field-name for both -- that is
just too confusing.  If a response header field is necessary, it
can be something like

Tracking: 0

and then I don't have to spend paragraphs trying to explain
directionality of messages to the reader (i.e., what DNT means
if it is received as a client as opposed to what it means as
received by a server).  Let me know if that is a problem.

....Roy

Received on Wednesday, 19 October 2011 06:08:38 UTC