Hi Sean, At Wed, 3 Oct 2007 21:36:57 +0000 (UTC), Sean Landis <[EMAIL PROTECTED]> wrote: > Yes you could but there's already a programming model for dealing > with HTTP methods. One could argue handle*() methods could be final > for example. Why exclude HEAD from that model?
Ah, sorry. I haven’t been using the getVariant/getRepresentation/etc. paradigm. Thanks for pointing that out. > > Why should you special case getRepresentation? > > Because HEAD shouldn't necessarily return a representation. Ah, looking further at the API I see what you mean. It does seem that the Variant class should contain all the data that is necessary to send back to the client from a HEAD request (size, mimetype, etc.) It does look as though the default code for a get calls a getRepresentation rather than simply determine the correct Variant, which seems all that is necessary when responding to a HEAD. > […] > Are you saying there's some place in Restlet where the entity is striped > out in the case of HEAD? You might be right, although I didn't see it. > Regardless, that makes unreasonable assumptions about the intent for > HEAD. I don’t know; it just seems to me that the place for the optimization which doesn’t call the code that returns the content of the response when we have a HEAD instead of a GET belongs there, not in a special case in your Resource. > > Also, intuitively allowHead is a bit redundant, since any resource > > that allows a GET really should allow a HEAD. > > That was John's point which I agree with. Default is true. Missed that. Thanks. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3
pgpQHBRICgPMF.pgp
Description: PGP signature
