Worldpay (The payment processor from RBS) sends a HTTP Post to my website once a payment is accepted. Problem is - the Post isnt getting through and my server responds with one of the following 3 HTTP error's:
HTTP 408 (Timeout)
HTTP 405 (Not allowed)
Invalid status line >NULL<
Now when i Post something to the url from my test php script this works fine which leads me to believe the issue could be with the fact that the Post from them is created by Java:
POST /worldpay_success.html HTTP/1.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: www.mysite.com
Content-Length: 116
User-Agent: WJHRO/1.0 (WorldPay Java HTTP Request Object)
authAmountString=%26%23163%3B1.99&_SP.charEnc=UTF-8&desc=Test.....etc
Does anyone have any experience with this? After speaking to Worldpay they say my server is responding with a 408 Timeout after 0.1 seconds so it doesnt seem to be properly timeing out... Any help apreciated
Paul
Check 405 Method Not Allowed and Request Timeout. It shouldn't matter if the POST request is created from Java.
Related
My team and I have a Tomcat server running a Restfull webservice, implemented using RestEasy:
#POST
#GZIP
#Path("/capture")
#Consumes(MediaType.APPLICATION_JSON)
Response RecieveData(#GZIP RecievingData recievingData);
We need to make compressed post to this service. The problem is we are not finding an implementation that works.
We tried using interceptors:
https://hc.apache.org/httpcomponents-client-4.2.x/httpclient/examples/org/apache/http/examples/client/ClientGZipContentCompression.java. But we were unable to capture the POST request Body and compress it.
We tried using the RestEasy client but it doesn´t seems to be compreesing the body of the Post Request: www.posttestserver.com/data/2016/01/06/15.33.391016591335
Finally we tried a customized class: https://gist.github.com/takumakei/913067. But we got a 400 error on the request:
HTTP/1.1 400 Bad Request [Content-Encoding: gzip, Content-Type:
text/html; charset=UTF-8, Date: Thu, 07 Jan 2016 10:07:05 GMT, Server:
Apache-Coyote/1.1, Content-Length: 66, Connection: keep-alive]
We are out of ideas and this supose to be a simple function for an HTTP Client. Any ideas?
OBS: Here is the RestEasy Proxy:
#POST
#GZIP
#Consumes(MediaType.APPLICATION_JSON)
public Response saveData(#GZIP RecievingData customer);
EDIT: Got some changes in the Firewall and the 3rd method changed to an error 400.
If using Tomcat why not add a RequestFilter that will pre-process received requests that contain header Content-Encoding: gzip and decompress it before the rest of the filter chain handles it?
EDIT:
I'm guessing your third option may actually have worked (snoop the network to verify), the issue was you got 403 - Forbidden response from the server. That's a problem with authorization not with the URL, request encoding, or anything else. The GZIP might actually be working for you right now.
EDIT:
Your latest output for HTTP response code 400 - Bad Request shows Content-Type: text/html. The Controller is expecting Content-Type: application/json, so the client did not set the ContentType as required by the Controller. Recheck your usage and config of the client code.
In the end I used the Resteasy framework for server and client to implement the GZIP compression.
Server side:
https://docs.jboss.org/resteasy/docs/2.3.0.GA/userguide/html/gzip.html
Client Side:
https://docs.jboss.org/resteasy/docs/2.2.1.GA/userguide/html/RESTEasy_Client_Framework.html
That worked for me.
I am writing a java program which responds to a basic request - using this as a reference - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
First time the browser sends a GET request without credentials.
I reply back with a 401.
out.println("HTTP/1.1 401 Unauthorized");
out.println("Server: My Test Server");
out.println("Content-Type: text/html; charset=iso-8859-1");
out.println("Accept-Ranges: bytes");
out.println("Connection: close");
out.println("WWW-Authenticate: Basic realm=\"myrealm\"");
out.println();
(out is the socket).
So the browser sends back the same request, but now with a username/password. If the username/password is correct, I send back and 200 & everything is hunkydory.
But if the username/password is wrong, I send back a 401 again (using exactly the same code I used for the original request without creds. In this case, I again get the same request with the same username/password as before. And I again send back a 401. This time the cycle stops.
One thing to note is the out of the 2 GET requests which come with credentials, the requests come with the same uname/password, but the order the request is different.
i.e.
First request with credentials
GET /basic HTTP/1.1
Authorization: Basic dHJ5OjEyMzQ1Ng==
User-Agent: Jakarta Commons-HttpClient/2.0.2
Host: IPAddress:Port of my program
2nd request with credentials
GET /basic HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/2.0.2
Host: IPAddress:Port of my program
Authorization: dHJ5OjEyMzQ1Ng==
About the user agent, I think Jakarta Commons-HttpClient/2.0.2 is the library used by the webserver to forward the request to my program.
What am I doing wrong here? Do bad credentials require a response different from no credentials? Or is this a problem with the program sitting between browser and my program(forwarding the browser's requests to my program). Is it sending the request just to make sure my program is not refusing the request because of the order of the original request?
Every server I've encountered sends 401 initially if no credentials are provided and then sends back a 403 error if the credentials are given but are invalid.
401 = you need to be authorised, please send me credentials
403 = I see your credentials and you're not authorised.
I wrote a simple Grizzly/Jersey application, which you can find here:
https://github.com/boldt/stackoverflow-14526627
I want to post some form data:
curl -X POST -F "name=test" -i http://localhost:9999/files
I'm getting the following response:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Fri, 25 Jan 2013 16:51:18 GMT
Transfer-Encoding: chunked
As you can see, the header is doubled, first a 100 Continue followed by a 200 OK. Is doesn't makes sense to get the 100 Continue.
Any suggestions?
This is normal. Curl is following the HTTP 1.1 spec. You are doing a POST which means you are going to be sending data to the server. Curl is sending a request header to the server with "Expect: 100-continue" in it.
This tells the server that the client wants permission to send a POST document and if the server responds with HTTP/1.1 100 Continue, then client sends the document (your form pairs in this case) otherwise the server may reject it for whatever reason with HTTP/1.1 417 Expectation Failed and this allows the client to not waste time sending lots of data possibly if it will be rejected.
There is nothing wrong with the two headers.
Read about the Expect header.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Check your request headers. You are probably sending HTTP Expect with curl.
curl -vv -X POST -F "name=test" -i http://localhost:9999/files
I've replaced the Tomcat by Jetty. Now I have 400 http error code for requests sent by a third party system. As I see, the difference with my tests sent by curl and a web-browser is the url in the http verb:
POST http://10.15.1.9:49302 HTTP/1.0
Host: 10.15.1.9
Content-Type: text/xml
Content-Length: 71065
User-Agent: hpost/0.1
Pragma: no-cache
Accept: */*
this request doesn't work, but post with relative URL such as POST / HTTP/1.0 works fine. Who is wrong? I cannot change the third party system, so, is it possible to make jetty accept such requests?
I've tried Jetty v6.1.26, v7.6.4 and v8.1.4 - works the same.
Ok, I think the reason is missing trailing slash after the url, the POST http://10.15.1.9:49302/ HTTP/1.0 works fine.
Does any body know if it is jetty problem or the client sends malformed url?
While the HTTP spec RFC-2616 says that the server must accept absoluteuri's for the request line, this is generally only used for proxy requests.
To Jetty, the request line POST http://10.15.1.9:49302 HTTP/1.0 is viewed as a HTTP/1.0 request, and fall into the rules of RFC-1945 for Request Line URIs that states absoluteuri's are always Proxy requests.
I've reported the issue, it is fixed now.
I make very simple HTTP server in Java. The response sent to the browser is
HTTP 1.1 200 OK
Server: OneFile 1.0
Content-Type: text/html; charset=utf-8
Content-Length: 202
Transfer-Encoding: chunked
<HTML><HEAD><TITLE>My website</TITLE></HEAD>
<BODY><H1>Document </H1>
</BODY></HTML>
mozilla firefox displays it as text/plain although it should be text/html Why?
I suspect the Setup info is ignored...is it any difference for browser if I make connection on port 8080?
Thanks for any help
The browser will honor your headers. Unfortunately, your response is malformed for several reasons:
the response should start HTTP/1.1, not HTTP 1.1
you specify Transfer-Encoding: chunked, but your response does not follow the chunked format.
It appears that Firefox, quite sensibly, refuses to interpret such malformed response and just shows it unchanged.