This is a bit of a specialist question as it concerns a very small embedded web server as opposed to a conventional web server (e.g. Apache, IIS) and it's more to do with the routing through the ISP.
I am the programmer responsible for implementing an embedded web server inside a hardware product. This is basically a consumer device that sits in a customer premises. The customer can optionally use the internal web server to perform configuration, and obviously they can port forward through their router if they want to so that they can access it from outside over the Internet.
I am trying to investigate a bizarre situation where a device installed at a particular premises is responding to requests for
.cgi files absolutely fine, and it will also respond with a
404 as it should do when a nonexistent file is requested. However, if a
.js (and no doubt many others) is requested, then what happens is the HTTP request hangs indefinitely and eventually times out. At this point, the browser just displays what it was able to load after that time, which is typically just the raw HTML without any of its image, style or script resources. (I'm seeing all this using the 'net' tab in Firebug.)
All I know about the device on the premises is that it's sat in a house which apparently uses the Virgin Media ISP, behind a pretty standard household modem / router. Unfortunately I'm unable to find out any more than that at the moment, and I can't physically get to it myself.
The HTTP server is presently configured for port 80.
The installer informs me that access to the HTTP server is absolutely fine when accessed at the premises locally; that is, all images and so forth load without issue. Furthermore, I've never, ever come across an issue like this with the product before. Stranger still is the fact that a previous product of ours installed there had pretty much the same web server inside - and didn't have this issue at all. So I've no idea if this could be conincidence or not.
Is there any possibility at all that the ISP could be applying filtering or otherwise somehow fiddling with incoming HTTP requests? At the moment this is the only straw I have to clutch at.
The web server in use is the HTTP server that is supplied as part of the Keil MDK-ARM library. The product is basically a small bit of custom hardware with an ARM processor, running a lightweight Keil RTOS that is also part of MDK-ARM. I don't believe that there is anything relevant I can state about the actual function of the box.
EDIT: Additional Wireshark clue
I've been taking Wireshark logs when I've attempted to just directly request a 'problem' file type, e.g. one of the
.js files. What I have found is this:
Rather than seeing a stream of one or more TCP packets that together form a valid HTTP response, aside from the usual ACK packets I instead only see a single TCP packet containing what is presumed to be part of the HTTP response. Wireshark marks this packet as "Continuation or non-HTTP traffic [Malformed packet]" because, due to lack of HTTP header in the packet, it can't tell what it is.
On further inspection I realise that these single 'malformed' packets I get whenever I request a problem filetype actually contain a payload of just four bytes of the actual requested HTTP file. For example, the packet's four-byte payload might be
ID=b, which corresponds with
ID=blahblah at the start of the
.js file I had requested. (I made that particular example up, but this is the consistent behaviour I'm seeing when requesting
So, in short, intead of getting back a complete HTTP response within one or more TCP packets and including a HTTP header, instead I'm just getting back a single packet with a payload of just four bytes that I know are four bytes of the original file being requested.
Edit 2: Further to the above, I've realised that any image that is very small in terms of bytes (say less than 1K) is successfully served back. It's almost as if it's okay as long as the response will fit into one TCP packet. Any larger than that, and the bizarre issue described above happens. But for .htm or .cgi, the response can be as large as it likes and it works.