Well... You've essentially run into one of the problems with the HTTP house of cards! There really is no clear way to deal with it either. HEAD was a nice theory, and it works fine for static content that gets updated now-and-then. But for non-idempotent requests (which in theory should always be POSTs) there just is no real way to work it. Either you DO perform the entire request, in which case HEAD is potentially non-idempotent and takes on the same characteristics as a POST (but remember, you cannot tell which method the server would normally expect, GET or POST from a HEAD...).
I guess the answer has to be that non-idempotent HEAD requests should be an error! The server obviously cannot really do the right thing. Personally whenever I write dynamic content generating systems I've always replied immediately to a HEAD with a response indicating that the resource has changed. Its not perfect, but at least you're telling a potential cache that it should re-request the resource. On Tuesday 29 July 2003 01:44 pm, David Nolan wrote: > --On Tuesday, July 29, 2003 6:43 PM +0200 Robin Berjon > > <[EMAIL PROTECTED]> wrote: > > I didn't see that one going in. Does it run through the process and send > > the right headers for size and all, or does it just stop after checking > > that the file exists? (former seems better to me) > > The latter would seem better to me. Because in the case of either a > content provider or XSP, processing the entire request may have side > effects. And it seems to me like HTTP HEAD requests should never generate > side effects. > > The same things can be said of AxTraceIntermediate, and > processing-instructions. I've had to put code into my provider to do its > own caching of a requests results, and output the same results if the > get_strref method is called more then once. It feels to me like I > shouldn't have to do that. > > > -David Nolan > Network Software Developer > Computing Services > Carnegie Mellon University > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Giant Electronic Brain Internet/E-Commerce Consulting Services --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
