Re: Solution to the CGI message trap

Actually, I think this one almost works:

   a) Add an Ack header field to all responses to mandatory HTTP requests:

	M-GET /foo HTTP/1.1
	Man: http://www.ext.com/my-extension
	...

	200 OK
	Ack: http://www.ext.com/my-extension

    The problem with this is that it will get cached by HTTP/1.0 caches
    regardless of whether we use the cache-control directive or not and
    hence may be handed out to another application thinking that it was
    its extension declaration that got acked.

Other protocols have faced a similar problem (e.g., TCP and
delayed-duplicate SYN packets).

Solution: think "nonce":

	M-GET /foo HTTP/1.1
	Man: http://www.ext.com/my-extension
        Ack-Nonce: "01dfds2374"
	...

	200 OK
	Ack: http://www.ext.com/my-extension, nonce="01dfds2374"

So what if this gets cached by an HTTP/1.0 cache?  The next
client will presumably choose a different nonce (suggestion:
use a function of the time+hostname for the nonce, just like an
RFC822 message-ID), and the wrongly-cached response will
be seen as an imposter.

Of course, we're talking about CGI URLs specifically, and
these (when the URL includes "?") are normally not cached
by HTTP/1.0 caches ... so this might be less of a problem.
But the nonce approach would eliminate all ambiguity, and
might be worth considering.

-Jeff

P.S.: If you believe that the recipient always does the
right thing with "Man:", then the Ack doesn't have to include
the URL, just the nonce.  E.g.,

	M-GET /foo HTTP/1.1
	Man: http://www.ext.com/my-extension
        Ack-Nonce: "01dfds2374"
	...

	200 OK
	Ack: "01dfds2374"

Presto, no cache-caused failures.

-Jeff

Received on Friday, 7 August 1998 16:44:28 UTC