|Subject:||Re: IdHttp 304 Response|
|Posted by:||Remy Lebeau (Indy Team) (firstname.lastname@example.org)|
|Date:||Mon, 28 Aug 2006|
"Ariel" <…@a.com> wrote in message news:A3619431AA05E34…@a.com...
> I'm using the TIdHttp component, and I have a problem.
Which version of Indy are you actually using?
> When the return code is 304, the component tries to read content
304 is one of a few specific replies that are strictly forbidden by RFC 1945
from sending any body content. However, buggy servers have been encountered
that do send body content when they are not allowed to.
> there isn't any content to read, so it waits until the timeout occurs.
A timeout is used in case the server sends body content when it is not
supposed to be.
> I debug it and it happens in IdHttp.pas in line 1035:
> "if AResponse.ContentLength > 0 then // If chunked then this is also 0"
> then it goes into IOHandler.ReadStream(...).
As it should be. The presense of a "Content-Length" header indicates that
there is actual data to receive (except in response to a HEAD request).
There should be no "Content-Length" header in a 304 response at all. 304 is
not a possible response to a HEAD request. It can only be sent in response
to a conditional GET request. If there is a "Content-Length" header in a
304 response, the then the server is most likely faulty, and there is not
much TIdHTTP can do about that.
> I think that when there is a 304 responsecode, it should just return
> an empty content, as fast as posible. no?
TIdHTTP is doing what the server said to do - the server is returning a
"Content-Length" header, so TIdHTTP tries to read as many bytes as are
specified. If the server is not actually sending those bytes, then the
server returned the wrong headers.
IdHttp 304 Response posted by Ariel on Mon, 28 Aug 2006