Streaming responses with chunked transfer encoding - async-await

We have a small proxy server written in .net. A simplified version of the core proxy functionality:
builder.Run(async ctx =>
{
using (HttpClient client = new HttpClient())
{
await client.SendAsync(BuildRequest(), HttpCompletionOption.ResponseHeadersRead)
.ContinueWith(t => t.Result.Content.CopyToAsync(ctx.Response.Body));
}
});
The idea is that the proxy will simply stream any downstream responses back to calling client as raw as possible.
The connection between the proxy and the service seems to working fine, always returning the 17kb of data i expect. The problem is between the client and the proxy, where sending the same request results in a response truncated somewhere between 0 and 17kb in length, apparently without reason.
When copying content from the service response to the client response, how can i tell when all of the content has been received? I know that chunked transfers are terminated by 0 length chunk, so do i need to check for this manually, or is this something handled by the httpresponse instance itself?

Related

Parse.com cloud code httprequest status code 200 zero bytes returned

I'm trying to make a httprequest from Parse.com cloud code, but although it returns response status code 200, it doesn't have any data with it (content-length: 0).
Because of my company privacy I can't post an URL on which the request fails, however it returns data successfully when used on http://www.seznam.cz/ or https://gmail.com/ (which returns 301 as a redirection issue, but still succeeds), so it's not caused by a https thing (my url is an api url with https)
Do you have an idea of why would the request succeed but return zero bytes, when in browser the data loads correctly?
Thanks!
It turned out that parse.com httpRequest doesn't use gzip decompression, and the api does, so although it received the response, nothing was returned since no data could be get.
I've overcome this issue by writing a php script posted on my web which get's the api's response, and prints it afterwards, therefore parse.com's httpRequest doesn't need to decompress the gzip and everything works as expected. I needed the same for images, by the way.

dart, turning a http request into a websocket?

I'm picking my way through the dartiverse_search example from the welcome page in dart editor. I see that it uses a path route to decide whether to transform a request into a websocket:
// The client will connect using a WebSocket. Upgrade requests to '/ws' and
// forward them to 'handleWebSocket'.
router.serve('/ws')
.transform(new WebSocketTransformer())
.listen(handleWebSocket);
Is it possible to turn a request into a websocket without using a routing path, for example using a query string to the root url?
You can specify any condition for upgrading to a WebSocket connection. You can even upgrade any connection request to a WebSocket connection without specifying a condition like this:
WebSocketTransformer.upgrade(request).then((WebSocket websocket) {
websocket.listen((String text) {
// process sent data
});
websocket.add(JSON.encode("Hello"));
});
If the request is not a valid web socket upgrade request a HTTP response with status code 500 will be returned. Otherwise the returned future will complete with the [WebSocket] when the upgrade process is complete.

Multiple URL opening in MFC

I am trying to send simultaneous request for opening URL in OpenURL() in CInternetSession class. But After sending 2 URLS requests, no other request can be send without receiving the response from previously send requests. How can I send a large number of URL request to a server and later only i want to process the response. Please help if any other API is there for sending multiple URL request to a server and receiving the response later. I want to use in MFC windows
The HTTP 1.1 specification (RFC 2068) mandates the two-connection limit.
In this way, WinInet (CInternetSession built on top of it) limits connections per server (MSDN).
You could try to invoke SetOption and adjust INTERNET_OPTION_MAX_CONNS_PER_SERVER and
INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER values. (MSDN)
Something like this:
sess.SetOption(INTERNET_OPTION_MAX_CONNS_PER_SERVER, 8);
sess.SetOption(INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER, 8);

Netty. Convert HttpRequest to FrameWebSocket and back

Can someone help me please?
I'm writing client-server application. Server and client are connected with websockets.
Pipeline for Server:
ChannelPipeline pipeline = pipeline();
pipeline.addLast("decoder", new HttpRequestDecoder());
pipeline.addLast("aggregator", new HttpChunkAggregator(65536));
pipeline.addLast("encoder", new HttpResponseEncoder());
pipeline.addLast("handler", new WebSocketServerHandler());
Pipeline for Client:
final WebSocketClientHandshaker handshaker =
new WebSocketClientHandshakerFactory().newHandshaker(
uri, WebSocketVersion.V13, null, false, customHeaders);
pipeline.addLast("decoder", new HttpResponseDecoder());
pipeline.addLast("encoder", new HttpRequestEncoder());
pipeline.addLast("ws-handler", new WebSocketClientHandler(handshaker));
This application works like a proxy - server get httprequest from outside, then sends it to client via websockets. Client receives it and sends it to modificated specified url, receives response and sends it back to server via websockets. Server receives this response and writes data into Channel that requested it.
The main question for now - what is the best way of converting HttpRequest into WebSocketFrame and back? Current idea is to read HttpRequest in string and then send it as TextWebSocketFrame. In this situation I think I'll need to replace those standart decoder that are specified for server and client currently for do not make double conversation. I did not find such decoder in Netty.
But mayby this is the bad way and there exists some more good decision?
Many thanks for answers! I'm new in netty.
Best regards
If you are planning to encapsulate the entire HTTP Request, then I think you are on the right track in sending it via a BinaryWebSocketFrame.

Problem with webclient: Expectation failed?

I have a custom Http Handler which manipulates HTTP POST and GET. I got the project working on a seperate isolated server now need to put it in production...
using (var client = new WebClient())
{
client.Credentials = CredentialCache.DefaultCredentials;
client.UploadFile("serverlocation:port", fileToUpload);
}
For some reason now when using client.UploadFile("", file); i.e. forcing the HTTP POST
System.Net.WebException: The remote server returned an error: (417) Expectation failed.
at System.Net.WebClient.UploadFile(Uri address, String method, String fileName)
What could this be? I know the code works, so what else? Maybe the server blocks HTTP POST requests?
I have tried adding:
ServicePointManager.Expect100Continue = false;
But have had no success though i'm not 100% sure where this code should before, I assume before i'm using the WebClient
Edit 0 :
I have just read the following:
Because of the presence of older implementations, the protocol allows
ambiguous situations in which a client may send "Expect: 100-
continue" without receiving either a 417 (Expectation Failed) status
or a 100 (Continue) status. Therefore, when a client sends this
header field to an origin server (possibly via a proxy) from which it
has never seen a 100 (Continue) status, the client SHOULD NOT wait
for an indefinite period before sending the request body.
I believe this request is going through a proxy, which may have something to do with the issue.
Edit 1:
Believe this problem has to be with 100-continue because, using fiddler to see exactly what my application is sending with WebClient.UploadFile shows this:
POST http://XXX.XXX.XXX.XXX:8091/file.myhandledextension HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------8ccd1eb03f78bc2
Host: XXX.XXX.XXX.XXX:8091
Content-Length: 4492
Expect: 100-continue
Despite having put that line: ServicePointManager.Expect100Continue = false; before the using statement. I don't think this line actually works.
I ended up solving this by putting the ServicePointManager.Expect100Continue = false; in the constructor for the calling WebClient class.
Then I used Fiddler to examine the POST request to ensure Expect: 100-continue was not in the request anymore.

Resources