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

I wrote:
>Consider this **somewhat contrived** example
>
>     client:
>     ## requesting first object, negotiating sticky headers ##
>     GET / HTTP/1.1<CRLF>
>     Accept: text/html<CRLF>
>     Accept-Language: en<CRLF>
>     Connection: sticky<CRLF>
>     <CRLF>
>
>     server:
>     HTTP/1.1 200 OK<CRLF>
>     MIME-Version: 1.0<CRLF>
>     Connection: sticky<CRLF>
>     Content-Type: text/html<CRLF>
>     Content-Length:94<CRLF>
>     <CRLF>
>     <94 bytes body data here>
>
>     client:
>     ## requesting second object, changing one of the to-be-sticky headers ##
>     GET /a.gif HTTP/1.1<CRLF>
>     Accept: image/gif<CRLF>
>     <CRLF>
>     ## requesting 3rd object, again changing 1 of the to-be-sticky headers##
>     GET /b.jpeg HTTP/1.1<CRLF>
>     Accept: image/jpeg<CRLF>
>     ## requesting 4th object, not sending one of the to-be-sticky headers ##
>     GET /c.gif HTTP/1.1<CRLF>
>     <CRLF>

Paul replied (I've reordered things a little):
    I don't see the ambiguity in this example. [...]
    I think maybe your example was just buggy (or not clear to me). If the
    client had sent the second request _before_ it got the reply from the
    server, then it would have been ambiguous as to whether
    "Accept-Language: en" was omitted from the request.

I think my example wasn't expressed quite right.  Not exactly
"buggy", but not clear enough.  I meant that the server would
transmit its "Connection: sticky" response at the point given,
but I did not mean to imply that the client necessarily received
it before making its second request.

    The server doesn't need to know when the client received
	    Connection: sticky
    instead, the client has to send requests that are unambiguous. I.e.,
    until it receives the
	    Connection: sticky
    it sends ALL headers that have ever been sent, which is unambiguous --
    even if the server thinks that the client *could* be omitting headers,
    none are actually omitted, so the server won't be confused.

I think this rule, which was not stated in your draft (as far as I
can tell) is almost right.  The problem is that, as stated, it might
require the client to send inappropriate headers for certain requests
(if, for example, the client's preferences varied based on some aspect
of the request-URL).  I would much prefer a more cautious specification,
that would work correctly independently of any assumptions we might
make know about the semantics of the request headers.

    >I can see several possible ways to solve this:
    >	(1) Explicitly declare that the client, after having sent
    >	"Connection: sticky", may start omitting headers as soon as it
    >	receives the server's "Connection: sticky" response, but MUST
    >	NOT change any such headers before receiving a response to the
    >	first request sent *after* it has received that "Connection:
    >	sticky" response from the server.  This rule has to be
    >	interpreted "per connection".  (If you draw out the timing
    >	diagram, you can see that this will always avoid the race
    >	condition.)
    
    I agree it needs to be per connection. I don't see why it has to
    wait the extra round trip. I think the modification above solves
    the problem.  If a client were _required_ to omit headers that were
    the same as in the last message once it had received the
    "Connection: sticky" from the server, then I think there would need
    to be tighter synchorization.

I'm not sure how to interpret that paragraph.  Does "the modification
above" refer to my #1, or your "the client has to send requests that
are unambiguous"?  If the latter, I would appreciate a careful 
definition of "unambiguous."   I'm not sure that "ALL headers that
have ever been sent" really works.

-Jeff

Received on Wednesday, 7 August 1996 14:00:54 UTC