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.
Related
When I try to send web requests (any kind) from Postman, it goes through the network and I can see the response. If I want to do the same from Python (I use spyder IDE), I get a http connection error.
Basically, the requests are timed out.
When I do a tracert to any host (i.e. google.com), after a number of hops the requests are getting timed out.
I'm on company network. We use dynamic proxy file to direct requests.
My question is twofold:
What is the root cause of the issue?
How can I fix it on my end? (Not involving company IT.)
Many thanks
I could solve this issue with the help of company IT. Problem was - if anyone interested - that I wrongly defined the proxy in the request itself, so that it never reached the proxy. Once I changed the proxy settings, the request could go through.
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.
We have a payment gateway integration that posts data to a third party URL. The user then completes their payment process and when the transaction is complete the gateway posts back to a URL on our server.
That post is failing and the gateway are reporting the following error:
ERROR 13326: Couldn't speak to ServerResultURL [https://foo.com/bar].
Full Error Details: The underlying connection was closed: An unexpected error occurred on a send.
Response object is null
When I post direct to https://foo.com/bar I get a 200 response as I'd expect so I'm not sure where this is falling down.
This is on an Ubuntu box running nginx.
What could be causing that issue and how can I find more detail about it and a way to resolve it?
EDIT:
For brevity the example above is on a URL of /bar but the reality is that I have a rewrite in place (see below). The URL that actually gets posted to is /themes/third_party/cartthrob/lib/extload.php/cardsave_server/result so I'm not sure if the rewrite below is what's causing an issue.
I would still assume not as I do get a 200 response when posting via POSTMAN.
# http://expressionengine.stackexchange.com/questions/19296/404-when-sagepay-attempts-to-contact-cartthrob-notification-url-in-nginx
location /themes/third_party/cartthrob/lib/extload.php {
rewrite ^(.*) /themes/third_party/cartthrob/lib/extload.php?$1 last;
}
Typical causes of this kind of error
I bet your server is responding to the POST to /bar with something that the gateway (PaymentSense, right?) doesn't expect. This might be because:
The gateway can't reach your Ubuntu box over the network, because a firewall or network hardware between the two is blocking it.
Your https cert is bad / expired / self-signed, and the gateway is refusing the connection.
A misconfiguration of NGINX or your web application software (PHP, I imagine? or whatever nginx is serving up) is causing /bar to respond with some odd response, like a 30x, or a 50x error page, or possibly with just the wrong response, such as an HTML page.
Something else is wrong with the response to the POST.
The script/controller running at /bar could be getting unexpected input in the POST request, so you might want to look at the request coming in.
You have a network connectivity issue.
I'll leave the first two items for you to troubleshoot, because I don't think that's what you're asking in this question.
Troubleshooting NGINX Responses
I recommend configuring it to dump its response into an nginx variable using body_filter_by_lua so that you can see what response is coming out. A good example of how to set this up is available here. I think that will lead you understand why /bar is not behaving.
Troubleshooting NGINX Requests
If that isn't revealing the cause of this, try logging the request data. You can do that with something like:
location = /bar {
log_format postdata $request_body;
access_log /var/log/nginx/postdata.log postdata;
fastcgi_pass php_cgi;
}
Review the request headers and body of this POST, and if the error isn't immediately apparent, try to replay the exact same request (using an HTTP client that gives you complete control, such as curl) and debug what is happening with /bar. Is nginx running the script/controller that you think it should be running when you make an identical POST to /bar? Add logging to the /bar script/controller process.
Use interactive debugging if necessary. (This might require remote Xdebug if you're working with PHP, but no matter what you're using on your server, most web application tools offer some form of interactive debugging.)
Network Troubleshooting
If none of this works, it's possible that the gateway simply can't reach the host and port you're running this on, or that you have some other kind of network connectivity issue. I would run tcpdump on your Ubuntu box to capture the network traffic. If you can recreate this on a quiet (network) system, that will be to your advantage. Still, it's TLS (https), so don't expect to see much other than that the connection opens and packets are arriving. If you find that you need to see inside the TLS traffic in order to troubleshoot, you might consider using mitmproxy to do so.
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).
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