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.
Related
I have read and tried the solutions shared in the previous posts for this error but nothing helped me to fix this. Kindly help.
I am making a HTTPS API call. A very simple call which accepts a 2 KB JSON message via POST method and sends a one word acknowledgement. It works perfectly fine in Postman tool. In JMeter, no. of threads (users) is kept as 25. It works perfectly fine one time with all 25 success response and at times getting few failure response as
Response code: Non HTTP response code: java.net.SocketException
Response message: Non HTTP response message: Unexpected end of file from server
No consistency at all. I have also tried with both enabling and disabling "use keepalive" checkbox. Both giving me all success one time ; few/all failure at another time with the above error. Please help. Thank you.
Below are the JMeter settings:
HTTP Header Manager : Content-Type - application/json
HTTPRequest sampler : protocol - HTTPS
Server Name or IP : project server name
Method : POST
PATH : The required path with https authentication details passed as parameters
IMPLEMENTATION : Set to JAVA (HTTPCLIENT4 was giving me “443 failed to respond” error)
Add header
Connection Keep-Alive
Both errors (Java implementation and Apache HTTPClient4 implementation), are essentially saying the same thing: The server closed the connection, without providing any response. I think there could be the following reasons:
Authentication problem. If server side checks authentication before processing a request (e.g. using Spring), it may be rejecting your request, it may be not bothering with any response if authentication is not considered correct.
Request Issue. Some less noticeable properties of the request you send via Jmeter are different from what you send in Postman. It could be some minor thing with formatting, or some headers server expects. Some of such inconsistencies can also cause Load Balancer (if you use one) to reject request before it's delivered to the server.
Certificate issues. Since you are using HTTPS, you need to make sure your certificate is setup correctly on JMeter side.
So I suggest:
Review server logs and see if your request makes it to the server. If yes, you might be able to see how it was rejected. If not, you need to trace back and see who rejected it (LB, authentication, etc)
Compare headers and body sent by JMeter vs Postman line to line (use TCPDump for example to obtain it).
All,
Every HTTP Request I make to my test REST Service is sent with the method set to GET. Tomcat rejects with a 405 - Unsupported Method. Doesn't matter what I change it to (POST, PUT, etc) Jmeter always sends a GET.
I set up the simplest possible test case by creating a Threadgroup with an HTTP Request Sampler and a View Results Tree. I send a JSON body to the REST Services which just echos back the request along with an ID. Works great with Google's REST Client UI.
Here is the result from the View Results Tree:
Response code: 405
Response message: Method Not Allowed
Response headers:
HTTP/1.1 405 Method Not Allowed
Server: Apache-Coyote/1.1
Allow: POST
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 1045
Date: Fri, 18 Jul 2014 21:39:27 GMT
Here is the RequestMapping from my REST Service
#RequestMapping(method = RequestMethod.POST, consumes = "application/json", produces = "application/json")
Here are some screenshots from my results. I wonder why there are two URI's below the HTTP Request in the tree? Notice the POST request looks correct.
Since the right answer is not provided yet: It's the "Follow Redirects" Option that causes this behavoir under certain circumstances.
see http://www.sqaforums.com/showflat.php?Cat=0&Number=687068&Main=675937
Try to end the 'Path' value of HTTP Request with '/'. It has to remove the GET result in View Results Tree.
I had the same problem. I tried everything also I read this question and all answers before find the thing that worked for me.
Content-Type should be application/json. It can not be text/html.
Set that in HTTP Header Manager. I assume you have set authentication details correctly.
We need to have three things properly set.
Content type which will be application/json
set the endpoint correctly in the path ,which you can see in soup ui
Check the port number on which the api wil get run on [All this u can first check on soupui and then try running the same in jmeter
I've written a class in Ruby that acts as an HTTP client. The code is minimal but the reason I'm not using 'net/http' is because this method allowes me to have more control over the requests being made and documentation for the HTTP is not helpful at all.
Anyway, the problem is the socket will only work for one request and response. Sending a second or subsequent request gives me an empty response.
For example:
Open connection to google
GET "/"
Response is the google.ca html
GET "/"
Response is empty
I tried closing and opening the connection between the requests but that only slowed it down and didn't fix the problem. I still got empty responses.
So what is the problem here?
Is there a method that lets me check to see if the TCPSocket object has an open connection so I don't accidentally open a new one?
Try:
require "socket"
host = "google.com"
port = 80
socket = TCPSocket.new host,port
request = "GET / HTTP/1.0\r\nHost:#{host}\r\n\r\n"
socket.print request
response = socket.read
This will return Google's main page. If you want to send request after request then change it to "HTTP/1.1" and read a response, then send the next request.
When communicating with our REST webservice, an http response with status code of 304 is returned to indicate that the resource requested hasn't changed. However our WP7 application, using the HttpWebRequest class, the phone is taking exactly 2 minutes before this type of response is successfully read.
HttpWebRequest request = HttpWebRequest.Create("path/to/unchanged/resource") as HttpWebRequest;
request.Method = "GET";
request.BeginGetResponse(
new AsyncCallback(
(aysncResult) => {
// response is read correctly here... 120 seconds later
}), null);
I can see that the webservice is responding immediately with 304 and no body data, the request itself is not timing-out and our application is able to successfully handle other response codes [404, 201 etc]. Could it be a Silverlight browser "caching" issue?
Can anyone confirm that they've seen this before, or have any thoughts on the issue?
Cheers,
Alasdair.
== Additional Information ==
As a result of WP7 restricting certain request headers, we use a custom [If-Modified-Since] header for all our resource requests. This custom header [X-If-Modified-Since] is recognised by the firewall in front of the webservice and modified back to the standard header. I'm unsure if this is related to the issue described above.
Answered my own question in case anyone is interested or facing a similar problem.
We eventually created a work around by configuring our webservice to respond with an OK (200) http status code, and writing the actual response code in a custom header X-Http-Status. On the client side when we parse the response, if this custom header exist then we take this to being the actual status code and continue with the business logic from there.
This allows us to potentially deal with any additional status codes that the Windows Phone handles differently.
The cause of the issue is still unknown, although we strongly suspect that since this is a NOT MODIFIED (304) code, some caching is happening at some low level layer in Silverlight before the response is made available to us.
I've started to add HTTP support to a custom C# non-webserver application which seems to work fine from Firefox/IE/Chrome when typing in the URL directly to the browser - where I can see a returned text string in the page from my application.
The problem is when I try do the same from a HTTPRequest in JavaScript on a web page I don't get a response with Chrome or Firefox (It's fine in IE) - rather I get a status of zero from the HTTPRequest object. I can however see that my application from its debug output received the request from the browser and provided the response so the browser must not be like the response I send in this case with the exception of IE being less picky.
I've swapped between trying different POST and GET requests to no avail - eg:
request.open('GET', url, true);
request.onreadystatechange = mycallback;
//request.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
request.send(null); //tried '' as well and other data with a POST
My simplest server reply I have tried is:
HTTP/1.1 200 OK\r\n
Content-Length: 20\r\n
Content-Type: text/plain\r\n
\r\n
...........
I have tried 1.0 instead of 1.1, different headers such as Connection: Close, Accept-ranges and other random stuff as I tried to mimic other such responses I looked at with Wireshark.
Obviously it must be something simple but the magic combination eludes me!
Many thanks in advance.
And on that note I have answered my own question it was the cross domain security feature.
Which I have now fixed by adding the extra response header:
"Access-Control-Allow-Origin: *"
Hopefully that is useful for someone else in the future!