[ee122] question about persistent connection

[Davide Cerri]

Hello,
>Actually, if the server does not include a content length or chunked
>header line, the client should assume that the server will send the file
>and close the connection after sending the last byte of the file. So the
>client will take everything after the HTTP header and save it as the file.

I have a problem understanding how can we use the headers for chunking
and content length to tell us if a connection is closed. I mean, the
absence of those headers tell us we won't have a persistent connection
if we are sent a file. But what if we ask a persistent connection and
we request a file that is invalid. The server will politely reply

"HTTP/1.0 404 Not Found: /spam/is-tasty.html"

and no header will be sent to the client. Now is the connection
persistent or not? Because if i base my decision on the lack of
headers, that would imply that the server would close the connection
every time a client ask for an invalid file.
Wouldn't make sense for the server to always add a header to notify
the client that the connection is being kept alive?

can somebody explain persistent connection more precisely?

thanks
Davide Cerri








>Important change to what I said earlier, read on:
>
>Daniel Killebrew wrote:
>> A persistent connection has nothing to do with the reply coming in
>> chunked or not. Persistent connection means the server won't close the
>> connection after the file is sent.
>>
>> But if you don't get a content length or chunked header line, you're
>> free to gracefully close the connection and indicate the error to the user.
>>
>Actually, if the server does not include a content length or chunked
>header line, the client should assume that the server will send the file
>and close the connection after sending the last byte of the file. So the
>client will take everything after the HTTP header and save it as the file.
>
>Professor Paxson pointed out:
>The reasoning behind this is, if the client says it wants a persistent
>connection,
>the server can *decline*. In that case, it can return an item with no
>content-length and no chunking and it's not an error, so the client in
>that case shouldn't close the connection when it sees the absence of either
>of those headers; it should read the item up to an end-of-file.
>
>Daniel

-- 
~/Davide Cerri