I am having some problems trying to get a post request to work from a payment provider (WorldPay) to my host server. Basically WorldPay does a callback to a script on my website if/when a transaction is successful. Problem is the post request isn’t getting to my script – we just get a 408 timeout.
This is the request sent from WorldPay below:
POST /index.php?route=payment/worldpay/callback HTTP/1.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: www.mysite.com
Content-Length: 711
User-Agent: WJHRO/1.0 (WorldPay Java HTTP Request Object)
authAmountString=%26%23163%3B3.49&_SP.charEnc=UTF-8&desc=testItem&authMode=A
And this is the response sent back from my hosts server:
HTTP/1.1 408 Request Timeout
Connection: Close
Pragma: no-cache
cache-control: no-cache
Content-Type: text/html; charset=iso-8859-1
I know this is a long shot but can anyone see anything wrong with anything above? To simplify things i replaced the php script with a basic html output which returned a hello world message and we still got a 408 so i’m pretty sure the script works. We have also had this error once or twice:
failed CAUSED BY invalid HTTP status line: >null<
Any help is greatly appreciated
Cheers
Paul
If the HTTP request you gave above is accurate, it seems as if the client is advertising a content length of 711 bytes, but the entity body does not seem to be 711 bytes long. That is why the server is timing out waiting for the rest of the data.
HTTP/1.1 408 Request Timeout,
pay attention to server config, if your host server is nginx, you can check "client_body_timeout" in nginx.conf
Related
I am trying to send data (json formatted string) as argument to Apache HTTP server with PUT method from arduino. The reply from server is 418 teapot reply.
This is my first project using TCP request, http, php - so I do not have a solid background in this direction.
The string :
{%221%22:%22FE005F719444%22,%222%22:%22ooooooooooxo%22,%223%22:%22ooooooooooxo%22}
TCP request:
PUT /proxyJson/index.php/?YOUR_data={%221%22:%22FE005F719444%22,%222%22:%22ooooooooooxo%22,%223%22:%22ooooooooooxo%22} HTTP/1.1 200 OK
Host: 192.168.xx.xxx
User-Agent: 192.168.xx.xxy
Content-Type: text/html; charset=iso-8859-1
Content-Length: 0
Connection: close
Apache access log:
192.168.xx.xxy - - [27/Dec/2016:19:50:22 +0200] "GET /proxyJson/index.php/?YOUR_data= {%221%22:%22FE005F719444%22,%222%22:%22ooooooooooxo%22,%223%22:%22ooooooooooxo%22} HTTP/1.1" 400 226
The script works just fine if enter data directly in browser.
What am I missing ?
Thanks for reply and support.
George
There is a mistake in your request.
The first line should be:
PUT /proxyJson/index.php/?YOUR_data={%221%22:%22FE005F719444%22,%222%22:%22ooooooooooxo%22,%223%22:%22ooooooooooxo%22} HTTP/1.1
Without the:
200 OK
Also, I recommend sending your data in the body of the request.
So your request would be:
PUT /proxyJson/index.php HTTP/1.1
Host: 192.168.xx.xxx
User-Agent: 192.168.xx.xxy
Content-Type: application/json
Content-Length: 58
Connection: close
{"1":"FE005F719444","2":"ooooooooooxo","3":"ooooooooooxo"}
That is the purpose of the Content-Type and Content-Length headers.
I'm using Apache 2.2 and PHP 7.0.1. I force chunked encoding with flush() like in this example:
<?php
header('HTTP/1.1 200 OK');
echo "hello";
flush();
echo "world";
die;
And I get unwanted characters at the beginning and end of the response:
HTTP/1.1 200 OK
Date: Fri, 09 Sep 2016 15:58:20 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/7.0.9
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
a
helloworld
0
The first one is the chunk size in hex (10 = A). I'm using Klein as PHP router and I have found that the problem comes up only when the HTTP status header is rewritten. I guess there is a problem with my Apache config, but I wasn't able to figure it out.
Edited: My problem had nothing to do with Apache but Nginx and chunked_transfer_encoding directive. Check the answer below.
This is how Transfer-Encoding: chunked works. The extra characters you're seeing are part of the encoding, rather than the body.
A client that understands the encoding will not include them in the result; a client that doesn't doesn't support HTTP/1.1, and should be considered bugged.
As #Joe pointed out before, that is the normal behavior when Chunked transfer enconding is enabled. My tests where not accurate because I was requesting Apache directly on the server. Actually, when I was experiencing the problem in Chrome I was querying a Nginx service as a proxy for Apache.
By running tcpdump I realized that Nginx was rechunking responses, but only when rewritting HTTP status header (header('HTTP/1.1 200 OK')) in PHP. The solution to sending Transfer-Encoding: chunked twice is to set chunked_transfer_encoding off in the location context of my Nginx .php handler.
I have come across this header for the first time and not sure what it does or mean. I have searched around and couldn't find what I was looking for.
I am trying to consume a SOAP API using PHP SoapClient class and it's returning an empty response and these response headers. Also, no exception is thrown.
HTTP/1.1 200 OK
X-Backside-Transport: FAIL FAIL,FAIL FAIL
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml
Date: Tue, 21 Jun 2016 20:09:50 GMT
X-Client-IP: xx.xxx.xxx.xxx
Any help is appreciated.
It seems that the web service you're trying to communicate is behind the xml firewall (probably IBM DataPower, it does send X-Backside-Transport header on failere) and blocks the error response (aka. fault message). This is the default behaviour for the xml firewalls. Root cause can be malformed soap message (i.e.: wrong data type) or an server site exception.
In order to solve the problem, you should contact with the web service owner.
I've seen this in the past when communicating with IBM Backends, in my experience it has also been joined with a HTTP 401 Unauthorised.
The reason for the error on my side was because of duplicate headers (e.g. sending the same head twice...)
Hope this helps.
Why do some web applications/servers/etc issue a non-standard, second, Status header. For example, I'm working with an existing application where, in addition to that HTTP protocal line, there's a second header named status
$ curl -I 'http://example.com/404'
HTTP/1.1 404 Not Found
//...
Status: 404 Not Found
//...
and a stock apache 404 doesn't include it
HTTP/1.1 404 Not Found
Date: Thu, 24 Jul 2014 13:16:28 GMT
Server: Apache/2.2.3 (CentOS)
Connection: close
Content-Type: text/html; charset=iso-8859-1
I'd write this off as one quirky application developer, but I've seen this behavior is other applications over the years, and the Wikipedia article on HTTP headers mentions this header, although it points out the header isn't included in RFC7230.
? "Status" is not listed as a registered header. The "Status-Line" of a "Response" is defined by RFC7230[23] without any explicit "Status:" header name.
Does anyone know the deal here? Is there some browser that needed this at some point? Still needs it? Is this some weird bit of SEO voodoo?
Is there any practical effect to including/not-including this field? Has there ever been?
(I'm specifically working with PHP, if that matters)
I'm attempting to stream chunked POST data using sockets in PHP to a local server for testing. This works fine if I don't chunk the request entity body and provide a Content-Length header.
However, when I chunk the transfer as follows the server doesn't recognize the end of the message. What is wrong with the raw message below that is preventing the server from correctly recognizing that the message is complete?
POST / HTTP/1.1
HOST: localhost
CONTENT-TYPE: text/plain
USER-AGENT: testing
ACCEPT-ENCODING: gzip,deflate,identity
TRANSFER-ENCODING: chunked
36
When in the chronicle of wasted time
0
After last '0' there are 2xCRLF, so the last 5 bytes are: 0x30, 0x0D, 0x0A, 0x0D, 0x0A.
I've tried sending this request to both a local Apache server and PHP5.4's built-in testing server. Neither can determine that the request is complete and execution hangs until the socket times out.
The value should be in hex 36 → 24