|Subject:||Re: Difference in operation of HEAD and GET when object doesn't exist|
|Posted by:||Remy Lebeau \(Indy Team\) (firstname.lastname@example.org)|
|Date:||Wed, 27 May 2009|
"Ross McMillan" <email@example.com> wrote in message
> If the object exists I get back a 200 response immediately from
> the Head request. If it doesn't exist Indy raises a read timeout
> exception after the read timeout has expired.
The only way I can see that happening is if the server's HEAD reply is
sending back a 'Content-Length' reply header greater than zero and TIdHTTP
is then waiting for the server to send the actual data, but the server is
not doing so. For a 200 reply, that makes sense, since that is how HEAD
works. But for any other reply, the server should be including body content
if the 'Content-Length' is greater than zero.
> If I use a TidHTTP.Get instead and the object doesn't exist the behaviour
> is the same, except that the exception occurs almost immediately.
> Why the difference?
Because HEAD works differently when a 'Content-Length' header is present.
Also, because we have encountered buggy servers before that do not follow
the rules of HEAD correctly, and so TIdHTTP's handling of HEAD replies tries
to take that into account as well.
> It seems like the server ignores a HEAD request for a resource that
> doesn't exist, and the 404 is being returned locally by Indy after the
> read timeout has expired
That is not what is happening. The 404 came from the server.
> whereas for a GET request the server sends back a 404 response as
> soon as it knows the resource is not present.
The same is true for a HEAD request as well.
> Where I have a lot of files to check for the existence of, it seems like
> using GET would be more efficient (I could say only request a chunk
> of 1 byte) rather than HEAD which seems to waste a lot of time
> waiting around.
You can thank buggy servers for that.
Remy Lebeau (TeamB)
Difference in operation of HEAD and GET when object doesn't exist posted by Ross McMillan on Wed, 27 May 2009