Subject: From: Date:

Re: [ECS] "Incomplete" POST data ? Ingo Pakleppa Mon, 14 Feb 2000 02:33:19 -0800

---

Great call, that makes sense. Note that the first call, too, contains a 
header "content-length: 23" which would indicate that there really IS 
content coming up. Incidentally, waiting for a double CR/LF may just happen 
to work for you, but it is by no means an officially permitted way of 
detecting the end of the transmission. The http 1.0 protocol only allows 
you one thing: look for the Content-length header. The actual content 
starts after the headers. The end of the headers is indicated by a double 
CR/LF (here, it is legal and even necessary to rely on CR/LF CR/LF). So in 
Mark's case, the header says "there will be 23 bytes of content following 
the headers". The first byte of content is the "i" (which is the first 
character after the CR/LF CR/LF). By the way, note that it is possible that 
some browsers may only send LF without CR, or LF/CR, or just CR. The 
standard says that you should only send CR/LF, but should be able to handle 
all four incoming.

Also note that http 1.1 adds another transfer mode, the so-called chunked 
transfer mode. This would be indicated by a header Transfer-mode: chunked. 
Content-length would be missing, and the first line after the header would 
be the (binary) length of a block (chunk) of content. The actual chunk 
starts right below that. After that chunk, a blank line follows, followed 
by the next chunk length, the next content, another blank line, etc. The 
end of transmission would be indicated by a chunk length of 0.

Actually, the maximum size Read returns depends on the TCP block size, 
which depends on the operating system you use, it's configuration, as well 
as on what kind of medium the call goes across - Ethernet, Modem, etc. - 
typical block sizes are a little over 1500 bytes and 570 or so bytes. This 
size is known as MTU (Maximum Transfer Unit).

Typically, you would get the smallest block that is supported anywhere on 
the connection between client and server. You'll get larger blocks when you 
connect to localhost, but there is no guarantee for anything anywhere.

Ingo

At 10:17 PM 2/13/00 +0100, you wrote:
>Mark Gilmore wrote:
> >
> > I am finding that when POSTing data (via a SUBMIT INPUT),
> > I am frequently NOT passed ANY data (about 1/2 the time).
> > Following are typical examples of what I am receiving
> > (only the last has the data). All I am doing is repeatedly
> > hitting the SUBMIT button. Is there some "trick" here that
> > is required to get ALL the data (assuming that the browser
> > is sending it) ?
>
>I experienced something similar.
>I came to the conclusion that I was waiting for a single READ event,
>while, instead, the full message may arrive split into several events.
>You have to wait for a terminator, which should be double CR/LF.
>I guess on a slow connection like "true" internet it could happen more
>often than on a fast intranet.
>I hope it helps.
>--
>Ciao,
>Dario
>--
>ADPM Synthesis sas - Torino
>--
>http://www.geocities.com/adpm99

---