Re: socket close() weirdness in 2.2 kernels: thank you!

Sam Gendler (sam.gendler@software.com)
Tue, 05 Oct 1999 15:58:51 -0700

I should add that there is a certain other browser that, at last check,
doesn't send a "\r\n" at the end of the posted data, which, according to
the latest HTTP spec is actually correct. However, since netscape does
send these bytes, it is best to have a stack that can either handle
closing a socket with data outstanding in a clean manner, or else where
you can check for the availabililty of data. A web server should
probably read Content-Length bytes from the client after the headers,
then query the socket to see if there is more data outstanding. If so,
read it. With the advent of real HTTP/1.1 compliance in netscape (if it
ever happens), they will be forced to remove the extra two bytes from
the posted data, since that would interfere with pipelining requests.
As it is, it makes persistent connections difficult. End of rant.

--sam

Martins Krikis wrote:
>
> Sam,
>
> Thank you very much for your answer. I didn't know there is another
> "\r\n" coming after the posted data, since the other systems never
> did send a reset to the browser when I closed the socket. And I
> was so sure that it wasn't there because of this buggy piece of
> test-code before close():
>
> if (j = read(fd, line, 2) < 0)
> {
> perror("read");
> break;
> }
>
> printf("Just got: %d, %s", j, line);
>
> I.e., I was setting j to the result of logical comparison, not to the
> actual number of bytes read and therefore thought I'm reading 0 bytes.
> Forgotten parentheses. I feel like a complete idiot.
>
> My apologies to everyone on the list for nagging you with this "bug"
> which appeared to have nothing to do with the linux kernel (except
> for the fact that in 2.0 I could close() the socket early with no
> consequences).
>
> Thanks,
>
> Martin mkrikis@kenan.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/