I have a DLL library, which I have no control over, that builds a XML message and sends it over HTTP to a web server. Due to the strict specifications, the server will only accept message with POST HTTP/1.1. However, the logs in the server shows receiving messages being POSTed HTTP/1.0. If I open the URL directly into a browser, the log shows GET HTTP/1.1, which is correct. We're not going through a proxy and the gateway isn't changing the version from what I can tell. I've tried on two different networks and I get the same error. Also, I have tried on Windows Server 2003 and Windows XP Pro, both of which should support HTTP 1.1.
Does anyone have any ideas why the server is receiving HTTP/1.0 using a POST, but using a GET shows HTTP/1.1?
Edit:
I've contacted the DLL maker about this, but their help isn't that great.
Edit 2:
Using Fiddler, I was able to extract the header, which is posted below. As you can see it's using HTTP/1.0.
POST /48A548C0BA8211DEA1EEE5AF2B3D5823;48A548C1BA8211DEA1EE8EF735B81699/
SJzWLaVEESCESCX6ESCESCW~ESC6FESCwxEuESCESCAb,L7ESCecvESCuESCESCrBESCHpESC3
ESCESCJw_ESCESClrj,ESC_4xESCOQpLwyRJGgp6p3YDG!uvXESCESC6!wVxESC7.dESCcTvmG5WM HTTP/1.0
Content-Type: application/xml;charset="utf-8"
Host: ***
Content-Length: 787
Sounds like you're out of luck seeing as you can't change the DLL. According to your response above in the comments, it seems like the DLL you're using is using HTTP/1.0 to send the HTTP requests to the server.
This is as good an answer as I can provide you with, given that you did not specify which DLL you are talking about or provided additional details.
I would suggest you to take a closer look at the DLL you're using to see if it is possible to instruct that library to use HTTP/1.1 for the requests it's sending out.
Good luck.
Write a server that acts a proxy, accepts http/1.0 obviousy, and then forwards to the destination server. This could work if you only have destination server. Otherwise get in touch with the vendor...... or perhaps take up reverse engineering as a side hobby.
Also on fiddler you should see the request and and response. You can correctly configure fiddler2 with any httpclient (besides just IE) using this reference: http://www.fiddler2.com/fiddler/help/hookup.asp
Related
I have a working console app, which sends data to an API. However as soon as I launch fiddler, I get the message:
[Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 257 bytes.
The first header shown in Fiddler is: HTTP/1.1 504 Fiddler - Receive Failure
which seems to be generated directly by fiddler rather than having come from my API server (.NET).
How can I debug why this is happening, given that fiddler will not show me the raw results from the server? I presume there is an HTTP header error of some sort, which is compatible with my console app but not compatible with Fiddler.
I have been playing with gzip compressed requests, so perhaps one of the headers is incorrect (Content-Length), but with no way to view the raw response, it's very hard to debug this problem.
In the end I got some help from #ErikLaw on this:
Download DebugView https://learn.microsoft.com/en-us/sysinternals/downloads/debugview
In Fiddler's black QuickExec box under the session list, type !spew and hit Enter. Fiddler will begin spewing verbose logging information to DebugView, including all reads and writes to/from the network.
Far more information about the failed request is then shown in DebugView, which led me to the root cause that my web server was closing the connection early, before sending all content.
All credit to Eric.
How can I debug why this is happening, given that fiddler will not show me the raw results from the server?
Use Wireshark to see the actual network traffic. Fiddler's good (it's great), but it's not Wireshark. You'll need to jump through some hoops if your traffic is HTTPS, though.
Wireshark is not as easy to use as Fiddler, but it is significantly more powerful.
Also, if you're on Windows, you need to use your machine's local network IP address (e.g. 192.168.x.y), rather than localhost. See this question.
postman is perfect!with it i can know most of the HTTP messages.but now i wonder if there is any tools like that one to help me know all the messages between my computer and outer world,not just the HTTP messages
I would recommend you to use fiddler, it's a web debugging proxy that I'm using most of the time on HTTP protocole but not only as you can capture FTP protocole for example.
You can also re-edit your request and have lots of interaction as web debugging :
http://www.telerik.com/fiddler
I have a MVC site with a Controller with a couple of methods for a partner to post to.
I can post to the web server from my local machine, across the WAN successfully.
My partner tries to post from his UNIX Server and it always results in HTTP 400 - URL.
I know the URL is good, and I know the response is good because I can post to it from multiple different network, but I am always posting from Windows.
He is posting:
POST domain.com/controllerName/action HTTP/1.0
Content-type: application/x-www-form-urlencoded
Content-length: 136
(Content-Length will be off because I changed the Request Body data for security purposes)
Parm1=Value1%0d%0aParm2=Value2%0d%0aParam2=Value3%0d%0a
I can take his data and post it from a Windows machine to the server just fine.
We were looking at the HTTP 1.0 value (this can't be changed from his side) and if perhaps IIS 8.5 on Server 2012 R2 was having an issue with it.
Has anyone had an experience like this? If so, do you have any information on how I can resolve the issue?
In the event that someone else has an issue like this, I will post the solution.
The code from my partner's Unix machine was opening a connection to domain.com
Then when it posted it was posting to domain.com/controller/action.
However, after some careful research and tracing, I discovered the Windows server was seeing it as domain.com/domain.com/controller/action.
Hence the 400 URL error in the log.
To solve the problem we updated on the Unix machine to open the connection to domain.com and then post to /controller/action.
Problem Solved.
I am writing http proxy server with support http/1.0. I use my proxy server in browser (google chrome). Proxy gets request something like GET www.site.com HTTP/1.1 and sends response HTTP/1.0 505 HTTP Version Not Supported. After that browser show me that error. However I expect that browser will make re-request with http/1.0 version (for example GET www.site.com HTTP/1.0). Whether I should send another response in order to get desired behaviour from browser? or it isn't possible? How to make the browser to work with http/1.0 proxy-server?
I guess, this depends on your browser. If you use Microsoft Internet Explorer, this might help: http://support.microsoft.com/kb/811262/EN-US
I haven't found anything about http protocol negotiation. A client could issue a "HTTP OPTIONS" request in order to detect the server's abilities, but there is no such requirement from the RFC 2616, Section 19.6. There's only an expectation for clients to understand lower protocol versions.
In a developement environement (where often the browser and the http server are on the same machine) i want to study the exact detail of authentication schemas. So i need to trace down every http request/response.
I've tried WireShark, that is very promising. But actually on
windows machines there is a problem in sniffing the traffic on
loopback interface.
Then i've tried a browser plugin, HttpFox
0.8.10 of Firefox 12. It is good in showing requests and responses, but in the specific case of authentication, it doesn't correctly
show the "double hop" authentication, it "collapses" the first
request (the Unauthorized status code) with the next, successful
one.
Then i've tried to work with the logs of httpd, that is my
actual server, but it is required a not trivial effort to create a
log that contains all the request such as headers (the authorization
header).So it doesn't seem a good "debug" technique.
Are there other possibilities?
Go with Wireshark. The answer to this question will address the loopback issue. Wireshark is the best because it really understands the formatting of everything related to HTTP (so long as you are not using HTTPS).