Why could I be getting error "The underlying connection was closed" when getting an Image? - .net-2.0

I'm using a little code to grab an image given its URL, and it's working for me for all URLs I tried except one:
http://title.mximg.com/img/logo/bizrealty.com.gif
For this URL, I'm getting "The underlying connection was closed: An unexpected error occurred on a receive."
However, if you open that URL with a browser, it loads perfectly.
Apparently that error message means:
"The underlying connection was closed:
An unexpected error occurred on a
receive."
--Seen when the client had sent the request in its entirety and got a TCP
ACK-FIN or RST from server to close
the connection, without a response
from server.
But I have no idea what that means :-(
The code is simply:
Dim req As System.Net.HttpWebRequest = DirectCast(WebRequest.Create(ImageURL), HttpWebRequest)
req.Method = "GET"
Dim resp As Net.HttpWebResponse = DirectCast(req.GetResponse(), Net.HttpWebResponse)
UPDATE: Setting KeepAlive to false doesn't help it. Also, it's not a timeout issue, I'm getting the error quite fast.
Any idea what could be going on?
Thanks!

I'd try updating your request settings like UserAgent or Accept. It's possible they're serving images dynamically and reject requests that don't look like normal traffic.

Related

Why is the browser satisfied with a response without content-length

Usually when I send a response to the browser I have to enter content-length in the http headers, otherwise the browser never stops loading (wait for more data)
But recently, I tested rust code:
let response = format!("HTTP/1.1 200 OK\r\n\r\n{}", contents);
stream.write(response.as_bytes()).unwrap();
The browser receives this without any problems, stops loading after receiving the response.(even though content-length is not specified in the response)
Can someone pls explain this?... What makes the browser satisfied with the response in this scenario (even though it does not contain: Content-length)
Content-length is optional as long as the connection is closed after the response is done. From RFC 7230 section 3.3.3 Message Body Length:
Otherwise, this is a response message without a declared message
body length, so the message body length is determined by the
number of octets received prior to the server closing the
connection.

Vertx request does not end on sendFile throwing

I'm new to vert.x and I'm trying to create a simple download service.
I used Request#sendFile(fileName) and it works well, but if I pass a directory path to Request#sendFile(fileName) it throws an exception, which is totally fine.
The problem is that, even if I catch that exception with an handler, I can't send any data nor end the request, an that leaves the http client (the browser) stuck on an endless spinning progress.
That is an example that reproduces the problem:
VertxOptions options = new VertxOptions();
options.setBlockedThreadCheckInterval(1000*60*60);
Vertx vertx = Vertx.vertx(options);
HttpServer server = vertx.createHttpServer();
Router router = Router.router(vertx);
router
.route(HttpMethod.GET,"/foo")
.handler(ctx->{
// this path exist but is not a file, is a directory.
ctx.response().sendFile("docs/pdf",asr->{
if(asr.failed()) {
ctx.response()
.setStatusCode(404)
// I can't end the connection the only thing I can do is close it
// I've commented out this lambda because is not what I want to happen.
// It's just an hack to end the request all the same.
.end("File not found: "+"docs/pdf" /*, (x)->{ctx.response().close();}*/ );
}
});
});
server
.requestHandler(router)
.listen(3000);
I can this problem by checking first if the path references to a file which both exsist and is not a directory (which in fact I did in the real code), but that leaves me with doubt about what would happen if the IOException was something different (like reading a broken file, or an unauthorized file ...).
When this error happens no data is sent through the wire, I've both checked form the browser and sniffing packets TCP packets (0 bytes send from the server to the browser).
The only things that works is closing the connection with Response#close(), which at least closes the keep-alive http connection, and ends the browser request.
What I want to achieve is to send some information back to the client to tell something went wrong, possibly setting the status code to an appropriate 4** error and possibly adding some details to it (either in status text or in the response body).
You should add failureHandler to your router:
route.failureHandler(frc-> {
frc.response().setStatusCode( 400 ).end("Sorry! Not today");
});
see https://vertx.io/docs/vertx-web/java/#_error_handling

QuickFIX/J: Is there any way to modify the logon response sent by the server

I am building a FIX adapter and the server I am hitting to response with 1137=FIX.5.0SP2.
My understanding is that 1137/DefaultApplVerId should be an enum. And QuickFIX/J throws up because it is expecting an enum value like 9.
13:46:00.628 [NioProcessor-12] ERROR quickfixj.errorEvent - org.quickfixj.QFJException: Unknown or unsupported ApplVerID: FIX.5.0SP2
org.quickfixj.QFJException: Unknown or unsupported ApplVerID: FIX.5.0SP2
Since I have no control over how the server responds. So my question is if there is any way for me to intercept and modify the response before it gets parsed by QuickFIX/J?

HTTP Sender and REST conventions

I'm writing a C# Web API server application, and will send JSON to it via a Mirth HTTP Sender destination. This post is about how to handle error conditions. Specifically, there are three scenarios I want to handle:
Sometimes we take the C# application server offline for a short period for system upgrade or maintenance, and Mirth is unable to connect at all. I want Mirth to queue all messages in order, and when the server is available, process them in the order they were received.
The server receives the request, but rejects it due to a problem with the content of the request, e.g., missing a required field. In accordance with REST conventions, the server will return a 400-level HTTP response. This message would be rejected every time it's submitted, so it should not be re-sent; just log the failure and move on to the next message.
The server receives the request, but something goes wrong on the server, and the server returns an HTTP 500 Server Error response. This would be the appropriate response, for example, when something in the server environment has gone wrong. One real-world example was the time the Web API server was running, but somebody rebooted the database server. REST conventions would suggest we continue to resend the message until the transient problem has been resolved.
For #1, initially I had it queue on failure/always, but it appears the response transformer never runs for messages that were queued (at least, the debug statements never showed in the log). I have turned queueing off, and set it to retry every ten seconds for an hour, and that seems to give the desired behavior. Am I on the right track here, or missing something?
For #2 and #3, returning any HTTP 400 or 500 error invokes the 1-hour retries. What I want is to apply the 1-hour retries for the 500 errors, but not the 400 errors. I’ve tried responseStatus = SENT in the response transformer, but the response transformer only runs once, after the hour has expired, and not for each retry.
This seems like a common problem, yet I’m not finding a solution. How are the rest of you handling this?
You're close!
So by default, the response transformer will only run if there's a response payload to transform. For connection problems, or possibly for 4xx/5xx responses that contain no payload, the response transformer won't execute.
However, if you set your response data types (From the Summary -> Set Data Types dialog, or from the Destinations -> Edit Response, Message Templates tab) to Raw, then the response transformer will execute all the time. The reason being that the Raw data type considers even an empty payload to be "transformable".
So turn queuing back on, and set your response data types to Raw. Then in the response transformer, if you look at the Reference tab there's a category for HTTP Sender:
You'll want the "response status line", that's the "HTTP/1.1 200 OK" line of the response that contains the response code. Here's a response transformer script that forces 4xx responses to error:
if (responseStatus == QUEUED) {
var statusLine = $('responseStatusLine');
if (statusLine) {
var parts = statusLine.split(' ');
if (parts.length >= 2) {
var responseCode = parseInt(parts[1], 10);
// Force 4xx responses to error
if (responseCode >= 400 && responseCode < 500) {
responseStatus = ERROR;
responseStatusMessage = statusLine;
}
}
}
}

Receiving Error Domain=kCFErrorDomainCFNetwork Code=2 when attempting to read from ReadStream

I'm attempting to synchronously read from a CFReadStream objected created by CFStreamCreatePairWithSocketToHost. The stream opened fine but when I attempt to invoke CFReadStreamRead on it in a loop, CFReadStreamRead() returns -1 and the resulting error is:
Error Domain=kCFErrorDomainCFNetwork Code=2 "The operation couldn’t be completed. (kCFErrorDomainCFNetwork error 2.)" UserInfo=0x14a920 {kCFGetAddrInfoFailureKey=8}
I'm also receiving this same exact error when using this ReadStream asynchronously- the first callback I receive is this error.
The short story: Probably a DNS resolution failure.
The docs say "The streams do not open a connection to the specified host until one of the streams is opened", and for kCFGetAddrInfoFailureKey,
Querying this key returns the last error code returned by getaddrinfo(3) in response to a DNS lookup. To interpret the results, look up the error code in /usr/include/netdb.h.
netdb.h says
#define EAI_NONAME 8 /* hostname nor servname provided, or not known */
I was able to fix this by putting in Google's DNS servers (8.8.8.8,8.8.4.4) in the wifi connection in the Settings app. The issue was that our devices were on a network that first required you to agree to some terms of service on a proxy login web page, much like hotels and coffee shops do. Safari worked fine after agreeing, but the app didn't, even after agreeing in Safari. Switching to alternate DNS worked (so did putting in the IP address instead of the DNS entry of our server, but I didn't want to hard-code an IP address).
I was able to eliminate this error by removing https:// from the host String.
NSStream.getStreamsToHostWithName("https://example.com" ...
You may need to set the appropriate security level:
inputStream!.setProperty(NSStreamSocketSecurityLevelTLSv1, forKey: NSStreamSocketSecurityLevelKey)
outputStream!.setProperty(NSStreamSocketSecurityLevelTLSv1, forKey: NSStreamSocketSecurityLevelKey)