We're developing code on an STR912, using uIP V1.0.  Up until now,
everything has been working fine (UDP including SNMP, Telnet, Ping,
etc).  Now I'm trying to implement a simple HTTP server, and am having
problems.

I first tried using Adam Dunkels's httpd.c and related modules from ST's
Ethernet library, but it doesn't quite work.  It responds to GET with a
single packet containing both the "200 OK" block and the first web page,
but the browser doesn't seem to realize that it's received the page, and
WireShark reports "TCP segment of a reassembled packet", which I believe
indicates that it thinks another packet will follow, though there
shouldn't be any need for one.

In the meantime, I tried generating my own responses manually, and I am
separating the "200 OK" response and the initial web page into separate
packets, as I've seen other web servers doing, but WireShark always
reports one error or another on my second packet, and the browser
(Firefox) never draws the page.

I have two questions (at least):

1. Is there something that documents how I'm supposed to generate the
second HTTP packet properly??
2. Is there some way I can get uIP to create that packet for me
automatically??  I don't see any way to get into the packet-building
code [ uip_process() ] unless I'm responding to an incoming packet...

I would be very grateful for any guidance that anyone could provide to
my on these issues!!

Regarding Dunkels' code, what I'm actually seeing is that, after "GET
...", it sends the complete packet as I described, the browser sends
back ACK, and the code responds by re-sending the entire packet again
(instead of just disconnecting), and this loops indefinitely... I wonder
why that's happening??  I need to look at how the ACK is being
handled...

Okay, nevermind my second post, that was a bug in my code, which I've
now fixed.

So the Dunkels code works the same as my code, if I try to send header
and web page in one packet.  Wireshark shows a single "TCP segment of a
reassembled packet" packet and nothing else, and apparently does not
realize that the first page was included in the packet.  The browser
apparently has the same problem, because it just sits and waits for
(nothing) to happen, and doesn't render the page.  I don't understand
what I'm missing.

I don't know too much about HTTP, but recently implemented a very simple
specialized webserver for lwIP and learned a few things.  I also used
uIP at one time so I'm somewhat familiar with that.

I'm not sure about your Wireshark error, but are you closing the
connection after sending the webpage?  I found that until I do that,
(Firefox here, too) the browser kept waiting for more.

You could give a Wireshark dump. That would help.

The problem is definitely not that Your Webserver sends Data and Header
in one package. Every usual Webserver does the same.
I assume your problem is, that
a) You say "Connection: close" in your Header
b) You don't send Content-Length in your Header
c) You don't close the connection on your webserver.

The result is, that the webbrowser waits for the webserver to close the
connection because it doesn't know how large the page is, and how much
bytes are actually left, before the whole webpage is successfully
transmitted. So it keeps waiting forever.

I have read in another forum that if you are doing HTTP/1.0, Connection:
close and Content-Length are not required.  At least it's working for
me.  When I send GET / via the web browser, it might send HTTP/1.1, but
I reply with 1.0 so including those items seems to be optional.

I know it is optional. It's even in HTTP/1.1. But the connection has to
be actively closed by the webserver in order the browser to recognize
the end of data.

Yep, that's the problem I'm having, all right.  I'm not ever sending the
FIN/ACK message after I'm done with my data.  I'm trying to debug that
right now.  I do get a message after my data packet, with UIP_ACKDATA
set and uip_len == 0, so I know I should be closing at this point, I
just gotta figure out why it's not getting done!

I was hoping I could sidestep the CLOSE issue by sending "connection:
Close", but that didn't work, and Simon K. confirms above that I
shouldn't expect it to, so I'll continue to focus on why I'm not getting
that packet out.

I thank all of you for this information, that has definitely clarified
what I've been seeing in WireShark over the last few hours!

Thank you all, again, for your help!!  I got that closing message going
back, and now all the pages work great!  My problem was that all the TCP
signalling was being handled in telnetd.c (I implemented Telnet before
I implemented Http in our application), and httpd.c was getting called
on newdata(), but not in any other situations... so setting closing
flags in httpd_appdata() was not doing any good!!  All is well now.

Hello ALL. I also have an example by Adam Dunkels. I have web-page with
form, submit button, which sends data to server by GET method. Do You
know how to read this sending from browser to server "get" string? I
can't found solution anywhere.