W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Sticky headers and pipelining (was: Sticky header draft -- as an attachment)

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Thu, 08 Aug 1996 17:26:06 -0700
To: Paul Leach <paulle@microsoft.com>
Cc: 'http-wg' <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <9608081726.aa19283@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1261
>>BTW, while we are on the topic, I would prefer that the two unrelated
>>concepts of sticky headers and short header names be in two separate
>>drafts.  They should be evaluated independently.
> I thought about that. I agree that they should be evaluated separately,
> and can be adopted independently. However, if both are adopted, using
> one mechanism (Connection: sticky) to say that you're using both saves
> some bytes on the wire. Even if sticky headers are in use, the use of
> abbreviations is not required, so a client that only wants to do sticky
> is not forced to do extra work. The only drawback I can see is if the
> client wants to do abbreviations but not do sticky headers. I don't know
> if that is likely.
> Unless there is some reason to believe that one will fly and the other
> one won't, then I'd personally avoid the overhead of a separate draft.

Okay.  Sticky headers adds statefulness to a protocol that is otherwise
stateless.  This means that protocol applications must be aware of things
like how much state is being stored, whether or not to allow it to be
stored, when to tell the client to pissoff because they have asked for
too much, how to tell the client to pissoff given the possibility of
pipelined requests, how to avoid introducing security holes in the process,
and how to do all the above in a way that is so efficient that it is
worthwhile even though the first two requests are unlikely to gain from
stickyness (due to the normal request profile of text, image, ...).
As such, I am adamantly opposed to the whole notion and have no intention
of implementing it.

Compressed header names (or, more accurately, tokenized header names) are
just a weak form of a fully tokenized protocol.  Full tokenization is the
way to go, and though I dislike halfway methods which will make
interpretation of things like the Connection header field ambiguous
(a list of header field names to remove from the message), I do not
adamantly oppose it.

I'm not sure if those are good enough reasons to split the draft -- I am
painfully aware of the editorial complications that arise when working
on more than one spec at the same time -- but I felt I should suggest it.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
Received on Thursday, 8 August 1996 17:30:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC