[En-Nut-Discussion] tap stream of Request

[Bernd Walter]

On Mon, May 09, 2011 at 12:12:57PM +0200, Harald Kipp wrote:
> Hi Werner,
> 
> On 5/9/2011 10:52 AM, Landsperger, Werner wrote:
> > Yes thats right, NutHttpProcessRequest() will just read in the HTTP
> > header but this function calls the function NutHttpProcessQueryString ()
> > which read out the inputstring and parses them into name and value. So
> 
> I'll try to answer with my half baked knowledge about HTTP. :-)

As usual - with my half baked knowledge about the code ;-)

> NutHttpProcessRequest() will only call NutHttpProcessQueryString(), if
> the URL contains a '?'.
> 
>  if ((cp = strchr(path, '?')) != 0) {
>    ...
>    NutHttpProcessQueryString(req);
>  }
>  ...
>  NutHttpProcessFileRequest(stream, req);
> 
> When using the POST method, there shouldn't be any '?' in your URL. You
> are sure your HTML form is set to POST instead of GET?

Technically it is leagal to do both of them.
Some website prgrammers add post requests with static url arguments
instead of adding them with hidden form objects.
But of course the url parameters are part of the header, unless you
try to parse POST arguments.
The ethernut version I use won't parse POST request - don't know if
it was added in the meantime.
However it should only be parsed depending on the contenttype.

But there is another HTTP uglyness when positing large data.
An HTTP-client might send the "Expect: 100-continue" header, in which
case it just send the header until the server ackknowledges that
it accepts the number of bytes.
The server has to send an "HTTP/1.1 100 Continue" in response for
the client to continue.
Most common clients expect a continue for requests bigger than a
given number of bytes, but continue anyway after a timeout in case
a server won't handle continue requests.
In the specification continue support is declared manadantory, but
a few server fail here, therefor the clients have the timeout workaround.

Probably ethernut has a smaller timeout as the client?

> When using POST, NutHttpProcessRequest() will only call
> NutHttpProcessFileRequest(), which calls NutCgiCheckRequest(),
> NutCgiProcessRequest() and finally your CGI function, which then should
> read and interpret the variables, which are part of the message body.
> 
> Can you see the HTTP parameters in the body?
> 
> > when I watch at the TCP/IP transaction via WireShark I can see that the
> > ethernutboard determines the connection. At first the board  send a
> > windowsize 0 message which would be asked again 2 seconds later from the
> 
> Announcing a TCP window size of 0 means, that the receive buffer is
> full. The peer is requested to try again by polling the window size...

And this likely means that the client is already sending the payload,
so I don't think it is the continue problem as such, but I think it
is still worth to be investigated.

Chunking support is also mandandory, but I've never seen any of the
major browsers to send data in chunks.
On the sending side however it can be usefull.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.