HTTP Demo (updated 11/22/2010 @ 12:35am)
Roy Eltham
Posts: 3,000
I've attached a zip file containing my HTTP Demo.
This demo uses my DHCP code, Kye's SDCard reader code modified to not need the DS1307 RTC plus use the spinneret pin assignments, STREngine from Timothy Sweiter's demo, and his Driver for the W5100. All of these are included in the zip.
It first uses the DHCP code to get it's IP info. Then it drops into a loop waiting for a TCP connection. When it receives an HTTP GET Requests it attempts to find the file on the SD Card (I don't support sub folders yet), if found, it sends the appropriate HTTP reply with the file. Then it loops back around, and waits for another connection.
Additionally in the zip file I have included a "Stuff to go on SDCard" folder which includes some HTM, PDF, and image files. Place these in the root folder of your CD Card. FAVICON.ICO is something that some browsers request. It will show up as the small icon on the page's tab or in the favorites list.
The demo requires all the files on the SD card that get served be in all uppercase and only have 8.3 names (since we can't do long file names), and it will not work without an SD card plugged in having at least INDEX.HTM on it.
New Stuff:
I've incorporated CassLan's code to read the MAC address from a file on the SD Card, as well as his code to retry DHCP when it fails. I also swapped in his propeller beanie favicon.ico. Thanks CassLan!
I took Beans code to parse the filename & variables, and expanded it to a more general ParseRequest call. There are also a ParseVars and DecodeString functions in there now. There's now two arrays, VarName[] and VarStr[], that contain the name/value pairs of the variables after the filename, as well as all the header fields in the request. The part at the end of ParseRequest that is supposed to parse POST stuff is untested, but it should work.
The code can now handle GET & HEAD requests, and I've stubbed in handling POST requests (doesn't do a Response yet).
This demo uses my DHCP code, Kye's SDCard reader code modified to not need the DS1307 RTC plus use the spinneret pin assignments, STREngine from Timothy Sweiter's demo, and his Driver for the W5100. All of these are included in the zip.
It first uses the DHCP code to get it's IP info. Then it drops into a loop waiting for a TCP connection. When it receives an HTTP GET Requests it attempts to find the file on the SD Card (I don't support sub folders yet), if found, it sends the appropriate HTTP reply with the file. Then it loops back around, and waits for another connection.
Additionally in the zip file I have included a "Stuff to go on SDCard" folder which includes some HTM, PDF, and image files. Place these in the root folder of your CD Card. FAVICON.ICO is something that some browsers request. It will show up as the small icon on the page's tab or in the favorites list.
The demo requires all the files on the SD card that get served be in all uppercase and only have 8.3 names (since we can't do long file names), and it will not work without an SD card plugged in having at least INDEX.HTM on it.
New Stuff:
I've incorporated CassLan's code to read the MAC address from a file on the SD Card, as well as his code to retry DHCP when it fails. I also swapped in his propeller beanie favicon.ico. Thanks CassLan!
I took Beans code to parse the filename & variables, and expanded it to a more general ParseRequest call. There are also a ParseVars and DecodeString functions in there now. There's now two arrays, VarName[] and VarStr[], that contain the name/value pairs of the variables after the filename, as well as all the header fields in the request. The part at the end of ParseRequest that is supposed to parse POST stuff is untested, but it should work.
The code can now handle GET & HEAD requests, and I've stubbed in handling POST requests (doesn't do a Response yet).
Comments
This is so much more convenient that coding the HTML inside the PropTool
The FAVICON is a very nice touch to add, I was drawing one last night, but no way to serve it without the filesystem tie-in
It will however, with google Chrome.
Also, after about 10 minutes of idle time... it will no longer respond.
Thanks for reporting the issues. I have had it randomly get into a "not responding" state. I think I have something getting stuck in a loop.
My testing has only been with Chrome and IE8 (the two I have on this machine). It's likely that I has something wrong in my implementation of transmitting large files, which may be what's making firefox not work.
I've been slowing working my way through the spec adding more stuff. So, hopefully, by the time I get through it all things will work better for all browsers.
Obviously, you have to make sure your HTML/etc stuff is compatible with the browsers you care about.
I won't be able to put much time into the Spinneret this week, since I have company visiting right now, and then I'm going out of town for Thanksgiving.
Roy