Can anyone guide me in acquiring the POST content-length of a website by just using sockets. Thanks and Kudos!
(I'm avoiding using httpwebrequest for some reason)
If it's a proxy application you don't need to be parsing headers at all. You just need to mirror the data from one side to the other, as bytes. The only thing you need to parse is for example the initial HTTP CONNECTION request, or whatever your initial handshake with the client is that causes you to set up the upstream connection. The rest of it is just byte copying and EOS and error propagation.
In the Http protocol the header is seperated from the content by a double crlf.
So you could either parse the header and get the Content-Length header or you can figure out the length of the content (since you know where the header ends and content starts).
HTTP/1.1 message length rules are described in section 4.4 of the RFC 2616.
Related
The response from the server is not a valid HTTP response. This problem occurs when the .NET Framework detects that the server response does not comply with HTTP 1.1 RFC. This problem may occur when the response contains incorrect headers or incorrect header delimiters.RFC 2616 defines HTTP 1.1 and the valid format for the response from the server. For more information, see RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 at Internet Engineering Task Force (IETF) website.
Get a network trace of the transaction and examine the headers in the response.
If your application requires the server response without parsing (this could be a security issue), set useUnsafeHeaderParsing to true in the configuration file. See Element
It seems like you just forgentting to clear the buffer before you receive new message.
2 quick options for you:
-add '\0' in the end of each of your messages on your server side. This will prevent gliches like that from happening.
-use Array.Clear(buffer,0,buffer.length) to clear buffer before receiving on your client side.
I'm making a server that should be able to store some images and then send/stream them to a client upon request. I've managed to get the server to respond with an image when I request it from a web browser, but when I send the very same HTTP request to the server from my client application, I'm not sure what exactly happens (it's supposed to become a tile map server at some point, but I'm starting out easy with just a single image here).
If it's of any help, here's an output from my web browser request: http://i.imgur.com/tG04qvS.png
And here the other one is: http://i.imgur.com/GUqdawF.png
Fiddler is saying I'm returning Content-Type: text/html; charset=UTF-8 which in my head sounds horribly wrong when trying to return an image.
I've been digging around a little more and it seems the response is empty. It smells like my server isn't delivering the image properly to the client since I'm just using this piece of code to respond to the request:
if (p.http_url.Equals("/MapServer/tile/0/0/0"))
{
Stream fs = File.Open("../MapServer/tile/0,0,0.png", FileMode.Open);
p.writeSuccess("image/jpeg");
fs.CopyTo(p.outputStream.BaseStream);
p.outputStream.BaseStream.Flush();
fs.Close();
}
I'm using StreamWriter for my stream. Is that the one giving me the content_type problems?
HTTP servers map content type through other mechanisms. A Stream is too low-level to convey that kind of information; it doesn't distinguish between series of bytes for a text file or an image.
The Content-type Saga
Content Negotiation
Configuring MIME Types in IIS 7
Try building your service to return something from the System.Net.Http namespace like HttpResponseMessage. These classes have the ability to provide more information about the type of document being sent.
I am sending a page to the client in chunks, by calling Response.Flush() in the middle of my page. This is so the browser will get the first part of the html, and can start downloading resources while my server continues to process the rest of the request.
Because of certain 3rd party services between my IIS server and my client (CDN, Firewall, Load Balancing, etc.) I need to set the header Transfer-Encoding: Chunked so they will know that the response will return in chunks.
I try setting the header by calling : Response.Headers.Add("Transfer-Encoding", "chunked");
For some reason when i do this, I get a blank page back after waiting quite a long time, even when contacting my IIS server directly, without going through all the 3rd parties. When attaching to process to debug, I don't see any errors.
Removing the 'Transfer-Encoding' header works, but I need this header for some of the 3rd parties I'm using.
Anyone know how I can set this header in my web application ??
Btw - I also tried setting this header in 'Response Headers' section in IIS directly, and the response is still empty when doing this.
According to the description on Wikipedia, Chunked Transfer Encoding requires the response body to be encoded in a specific way, one of main points of the described format being :
Each chunk starts with the number of octets of the data it embeds
expressed as a hexadecimal number in ASCII followed by optional
parameters (chunk extension) and a terminating CRLF sequence, followed
by the chunk data. The chunk is terminated by CRLF. If chunk
extensions are provided, the chunk size is terminated by a semicolon
followed with the extension name and an optional equal sign and value.
As far as I know, calling Response.Flush() does not generate this specific markup. It just empties any buffered response content to the client.
You may have a look at "When does the server use chunked transfer encoding?" in this answer :
https://stackoverflow.com/a/2711405/1236044
It seems to imply that, with the correct settings, IIS should automatically switch to Chunked Transfer Encoding when needed
The server will be using chunked transfer encoding if you disable buffering:
Set context.Response.BufferOutput to false
According to this question
You might further need to set Server.ScriptTimeout (in seconds) to avoid your script being interrupted.
I would like to extract the HTTP header information using Packet.Net. I am using SharpPcap to capture the packet and need to access the User-Agent field in the TCP packet. If I understand correctly Packet.Net is used to analyze the packet captured. Help would be appreciated on this regard. I have tried to display the TCP packet with the following code but I get bytes displayed. I am using C# as development language.
private static void device_OnPacketArrival(object sender,CaptureEventArgs packet){
Packet p =Packet.ParsePacket(packet.Device.LinkType,packet.Packet.Data);
System.Text.ASCIIEncoding ASCII = new System.Text.ASCIIEncoding();
String StringMessage = ASCII.GetString(p.Bytes);
Console.WriteLine(StringMessage);
}
Packet.Net doesn't currently have http decoding support. Because http messages can be split across multiple packets, it seems like a good approach would be to first add support to allow the following of tcp connections, then add http session detection and parsing on top of the tcp data stream. Trying to parse http data on a per-packet basis might work for the headers of the data or some http messages but isn't a robust solution as it would prevent being able to get the full content of the http message that might be several kilobytes in size.
(I have a commercial library that builds upon SharpPcap/Packet.Net that adds tcp session following and http session following and decode. Post your email here if you want me to email you with more details.)
My ASP.NET app returns JSON object to user, it contains binary encoded data. Due to this I decided to enable HTTP compression and the problem begun with Content-Length.
If I enable compression the Content-Length header is ignored while response s send and connection is not closed immediately. The connection is still open for about 15 seconds after all data has been sent.
I would like to have HTTP compression enabled but don't know how to solve the problem with Content-Length header.
context.Response.AddHeader("Content-Length", jsonObject.ToString().Length.ToString());
context.Response.Write(jsonObject);
context.Response.Flush();
context.Response.Close();
Content-Length represents the length of the data being transferred in your case it is the compressed bytes. See this SO question whose answer links to relevant RFC: content-length when using http compression
In case, HTTP Compression is happening via web server (and not by your code) then I will suggest you to try adding content-length header by your self. Hopefully, web server will add it correctly.
This can be verified using Chrome on http://httpd.apache.org/ if you look at the developer console you would see the Content-Length to be much smaller than the actual uncompressed page in bytes.