I've seen this issue happen on multiple machines, using different languages and server-side environments. It seems to always be IIS, but it may be more widespread.
On slower connections, characters are occasionally missing from the response body. It happens somewhere between 25% and 50% of the time but only on certain pages, and only on a slow connection such as VPN. A refresh usually fixes the issue.
The current application in question is .NET 4 with SQL Server.
Example:
<script>
document.write('Something');
</script>
is being received by the client as
<scrit>
document.write('Something');
</script>
This causes the JavaScript inside the tag to instead be printed to the page, rather than executing.
Does anyone know why this occurs? Is it specific to IIS?
Speaking generally, the problem you describe would require corruption at the HTTP layer or above, since TCP/IP has checksums, packet lengths, sequence numbers, and re-transmissions to avoid this sort of issue.
That leaves:
The application generating the data
Any intermediate filters between the application and the server
The HTTP server returning the data
Any intermediary HTTP proxies, transparent or otherwise
The HTTP client requesting the data
The user-agent interpreting the data
You can diagnose further based off of a network capture performed at the server edge, and at the client edge.
Examine the request made by the client at the client edge to verify that the client is making a request for the entire document, and is not relying upon cache (no Range or If-* headers).
If the data is correct when it leaves the server (pay particular attention to the Content-Length header and verify it is a 200 response), neither the server nor the application are at fault.
If the data is correct as received by the client, you can rule out intermediary proxies.
If there is still an issue, it is a user-agent issue
If I had to psychically debug such a problem, I would look first at the application to ensure it is generating the correct document, then assume some interloper is modifying the data in transit. (Some HTTP proxy for wan-acceleration, aggressive caching, virus scanning, etc...) I might also assume some browser plugin or ad blocker is modifying the response after it is received.
I would not, however, assume it is the HTTP server without very strong evidence. If corruption is detected on the client, but not the server, I might disable TCP Offload and look for an updated NIC Driver.
Related
I have this script where I'm taking a large dataset and calling a remote api, using request-promise, using a post method. If I do this individually, the request works just fine. However, if I loop through a sample set of 200-records using forEach and async/await, only about 6-15 of the requests come back with a status of 200, the others are returning with a 500 error.
I've worked with the owner of the API, and their logs only show the 200-requests. So I don't think node is actually sending out the ones that come back as 500.
Has anyone run into this, and/or know how I can get around this?
To my knowledge, there's no code in node.js that automatically makes a 500 http response for you. Those 500 responses are apparently coming from the target server's network. You could look at a network trace on your server machine to see for sure.
If they are not in the target server logs, then it's probably coming from some defense mechanism deployed in front of their server to stop misuse or overuse of their server (such as rate limiting from one source) and/or to protect its ability to respond to a meaningful number of requests (proxy, firewall, load balancer, etc...). It could even be part of a configuration in the hosting facility.
You will likely need to find out how many simultaneous requests the target server will accept without error and then modify your code to never send more than that number of requests at once. They could also be measuring requests/sec to it might not only be an in-flight count, but could be the rate at which requests are sent.
I have an Azure application that connects to a large installed base of devices. Everything has been working fine for years until today when everything has stopped working. What I think has happened is Azure is now segmenting the small (87 byte payload) message and this has exposed a bug in my TCP handler.
Does anyone know if there is a way of forcing Azure not to segment small TCP messages?
Follow up - I think this is because the HTTP message is 'chunked' and send as 2 TCP segments. There is a bug in my code that does not handle chunks which as only now surfaced.
Can I turn off chunking in Azure?
If your question is whether there is a way to prevent a HTTP response from using HTTP Chunked Transfer Encoding, then perhaps, depending on the server-side APIs you are using. Setting a Content-Length header usually suffices.
But I think your question is whether you can force Azure to buffer IP packets in a way that avoids the bug in your client, which is assuming that a single socket Read() will return a complete message. In which case, no. It may not even be within Azure's control, as any intermediate router could cause a delay in the delivery of packets, which, in turn, will cause the client's Read() to return a partial message.
I found a solution here Disable chunking in Asp.Net Core
In summary:
response.Headers["Content-Encoding"] = "identity";
response.Headers["Transfer-Encoding"] = "identity";
This seems to disable unnecessary chunking. I have no idea how
I have been studying web sockets recently and plan to use them in my application even though the app is not realtime. I am mostly doing this because I want to try it out and further down the line it might open more possibilites for the app's functionality. Also I am not bothered about having an API for mobile at the moment but think it would still be possible to have some kind of api over web sockets if I needed it in the future.
However for in-production apps are there any real reasons why somebody would consider implementing websockets if there is no real-time element?
Are there any benefits over HTTP requests other than the real timeness of it?
HTTP requests include the full HTTP headers. Depending on the cookie load, this may reach a couple of KB per request. WebSocket protocol headers are minimal compared to that. If you have a lot of requests and care about bandwidth then going with WebSocket makes sense.
Additionally a HTTP connection is (traditionally) negotiated for each request, which means you have overhead on each request compared to WebSocket, which has persistent connections. Connection establishment takes time (hence the advantage in real-time applications), but it also uses resources on the server. Again, depending on your app's communication patterns, using WebSocket may make sense.
My server send some data to the mobile app
The user does some operations with those data and sends other objects back to the server, which contains the data that the server first sent (PS: of course those objects are created by the mobile app through user interaction)
Before the server persist mobile's data, should I validate if the server data inside it is consistent? Because if it's not, it will cause a exception.
But if you know it will cause a exception, why don't you avoid it?
Because I'm relying on:
Mobile app to be working 100% and send consistent data
Authentication between requests so it's not forged
Extra overhead checking something that normally would be OK, unless someone hacks it
Yes, you should validate and sanitize all inputs on the server side. Authentication doesn't help with integrity. If I am an attacker, I can make HTTP requests using CURL bypassing any security control you may have in your app.
specifically, i'm talking about from the point of view of a node.js server. it's hard to test this in node.js because http.client validates content-length.
can a client lie about a body's content-length, at least at the point it reaches http.createServer().on('request')?
Can a client send a body that is larger than content-length? I don't think this is possible as it is most likely checked at the parser level, but i want proof.
Can a client send a body that is smaller than content-length? I think this may be true.
i'm worried about malicious users that may not use a well-behaved http client.
Of course it's possible. You could simply open a TCP socket connection to whatever IP/port a web server is running on and write anything you'd like there. Of course well-behaved clients don't do this, but there's nothing stopping a client from doing so.
However, this tends to be whatever HTTP stack your using on the server's problem, in this case node. It needs to 1) not blindly read in (huge) content-length bytes as that could crash the server miserably and 2) make sure (for reasonable-sized requests) that the client isn't lying.
In the case of node, it's visible right about here: https://github.com/joyent/node/blob/master/deps/http_parser/http_parser.c#L1471
Just try it and see ;-)
it depends
of course you can send a wring content length, the question is what does the client do with it.
there are script or server clients that may attempt to download your content and get completely messed up.
most browsers seem to have some error tolerant behaviour implemented however there are many differenet implementations.
i remember having a old ie keeping the socket open never closing it. this ended up in a never ending page load.
some netscape browser seem to be totally dependent on the right content length.
a good idea is to leave content-legths away. this should work on every browser.