Hi Aaron
Chrome is a bit strange and it deviates a little from other web browsers. Here is a copy of an email that I sent when looking into this about two months ago when it was first noticed that Chrome wouldn't even display a web page.
I don’t think that you have tested with Google’s Chrome – I found that it didn’t allow any HTTP operation with the uTasker HTTP server due to the fact that the server doesn’t report “HTTP Version 200 OK” as answer to each request. Chrome doesn’t like this and immediately resets the connection. The error message is a bit misleading since it states that the server cannot be found.
So I added a fix for this.
Then I found that parameter posting didn’t work either (file posting did though). It turned out that Chrome handles this a little differently and, especially interesting for you, it doesn’t post any parameters in the first TCP frame!! Instead it uses the first TCP frame that it sends purely for header content, followed by the data. This is something which we discussed earlier and so I had no choice but to handle this over two frames (not multiple since the restriction is still that the complete data should be in once frame – but the data can be longer since it is the only content…).
I haven’t heard any complaints about this just yet but they are sure to come so I have a trial patch ready.
In case you need to check this out with Chrome I have attached the files needed. In HTTP.c just look for SUPPORT_CHROME. In tcpip.h I added a new HTTP state HTTP_STATE_DOING_PARAMETER_POST as well as an optimization for the simulator (iFetchingInternalMemory in the HTTP struct) which is not needed unless actually working with the simulator.
As you can see there is a patch available which has been tested successfully for some time now. It hasn't found its way into any service packs in the mean time though.
There are a number of changes in the HTTP required and so it is not possible to post these here. If you would like to receive these (with fixes as per the email) please contact me per email and I will send them to you.
Regards
Mark
PS. Additional finds (which are solved in even newer development versions are:
"In the case of posting ASCII files CHROME doesn’t advertise the file type at all – so a missing file type has to be considered as plain text…). It also closes HTTP1.0 connections with TCP resets rather than FINs (a bit strange) – a few too many differences in the details for my liking…"