Re: Solution to the CGI message trap

From: Henrik Frystyk Nielsen (frystyk@w3.org)
Date: Fri, Aug 07 1998


Message-Id: <3.0.5.32.19980807171945.034ae8f0@localhost>
Date: Fri, 07 Aug 1998 17:19:45 -0400
To: Jeffrey Mogul <mogul@pa.dec.com>
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: ietf-http-ext@w3.org, lawrence@agranat.com, paulle@microsoft.com
Subject: Re: Solution to the CGI message trap 

At 13:44 8/7/98 MDT, Jeffrey Mogul wrote:

>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.

Yes, I was thinking of extending the namespace (ns) parameter to support
this including only sending back the namespace ID because as you say, this
is enough.

It would also give explicit information about which extensions had been
fulfilled in the case where the request contained a mix of mandatory and
optional extensions.

Then I ran into thoughts about too much overhead of adding potentially
several UUIDs to each request and not being able to see the result without
parsing the whole message and went for the 102 (Extended) code instead. You
can find the write-up at:

	http://www.w3.org/Protocols/HTTP/ietf-http-ext/

This would of course not work through 1.0 proxies. Hmm, now I don't know.

>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.

I agree, the most important thing to solve is definitely that we get 200
back from a CGI script on DELETE etc. and it's probably relatively seldom
that the responses are actually cached in 1.0 caches.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk