I have an app which connects to my web server and transfers data via XML.
The headers I connect with are:
POST /app/API/Data/Receiver.php HTTP/1.1
User-Agent: Custom User Agent 1.0.0
Accept: text/xml
Content-Type: text/xml
Content-Length: 1580
Host: servername.com
The app then handles the data and returns its own XML formatted reply. One of the header's I'm setting in the response is:
header("Connection: close");
When I send connect and send my data from a simple app on my PC (C++) it works fine, I get the close header correctly and the connection is closed as soon as the data is available. When I send the exact same data using a GSM modem and and embedded app, the connection header comes back as:
header("Connection: keep-alive");
The GSM modem also sits and waits until the connection is closed before moving on and often just times out.
Is there someway to close the connection on the server so that the GSM side does not time out?
It is possible that your GSM service provider transparently proxing connections. Try to send data on non-standard port (i.e not 80, 8080, 443)
Also setting cache control header private might work.
Cache-Control: PRIVATE
Headers are just plain text but cannot be sent once data has been sent in PHP. Try this:
echo "\r\n\r\nConnection: close";
die();
and adjust to your needs
Related
we're using a custom built cart system and during high loads our payment system (Worldpay) times out.
When this happen we receive an email containing the POST request that failed, and this is a .txt file done like the following:
POST /index.php?xxx=yyy&zzz=xxx HTTP/1.0
Content-Length: 917
Host: ourdomain.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
User-Agent: WJHRO/1.0 (WorldPay Java HTTP Request Object)
parameter1=value¶meter2=value2
How can I actually quickly resend this request to my server so it can register the payment now that the load is more normal? I have this in a .txt file, is there a quick way to do it using this file as it is? Curl? Browsers? In a way so I can see the response to check that all is ok.
Thanks so much!
Depending on the needs you have exposed, it is likely that tools such as POSTMAN could help you, allow you to send http requests through an intuitive interface, you can use the various parameters, that are sent to you in the file you mentioned and run the same request check for any errors.
I have been given a task to write a web service to push data from sensors to the server database.
I have written a PHP webservice which takes some arguments in GET, process the data in it and stores the data in the database.
Example
http://www.example.com/pushDataService/index.php?arg1=<Data 1>&arg2=<Data 2>&arg3=<Data 3>
But our firmware programmer wants something that he can test on a command line.
Just like SMTP communication using telnet
Example
Telnet mail.example.com 25
EHLO mail.example.com
AUTH LOGIN
UserName encrypted in base 64
Password encrypted in base 64
MAIL FROM:<test#example.com>
RCPT TO:<test#domain.com>
DATA this is a test message.
Can I make the webservice work like this where he can do the handshaking process in command line and then each argument is sent individually and user get a response for each argument ?
Please help, I am new to PHP and have no idea of (web) service like this!
Thank you
Edit:
We are already using MQTT to push the data to the server but we need another server to push data which will work as a combination of SMTP mail server and MQTT protocol...
Will a SOAP web service do the job for me?
The http://www.example.com/pushDataService/index.php?arg1=<Data 1>&arg2=<Data 2>&arg3=<Data 3> request can be done Just like SMTP communication using telnet as following:
Telnet www.example.com 80
GET /pushDataService/index.php?arg1=<Data 1>&arg2=<Data 2>&arg3=<Data 3> HTTP/1.1
Host: www.example.com
<CR>
<CR>
Pushing data with GET requests is not the best idea. PUT or POST requests would be more suitable. First of all it is not idempotent and should never be cached, and what is more important - it is way more flexible in data format and size. The POST request sending json data may look like
Telnet www.example.com 80
POST /pushDataService/index.php HTTP/1.1
Host: www.example.com
Content-Type: application/json; charset=utf-8
Content-Length: 57
{"arg1":"<Data 1>", "arg2":"<Data 2>", "arg3":"<Data 3>"}
I'm seeing these two headers in my response header of an AJAX call. Need to know more about this and what is the meaning of this header? Is this implies to caching of data from server?
X-Cache:MISS from localhost
X-Cache-Lookup:MISS from localhost:3128
I'm trying to get working WSO2 ESB 4.7.0 with PHP 5.4.9 SoapClient.
I've got a problem when I use SoapClient in WSDL mode with ESB echo service, that connection from ESB is not closed after sending WSDL. I'm able to reproduce this problem also with telnet as client.
$ telnet localhost 8280
HTTP 1.0 request:
GET /services/echo?wsdl HTTP/1.0
HTTP 1.0 response:
HTTP/1.0 200 OK
Content-Type: text/xml
Date: Mon, 29 Jul 2013 07:37:20 GMT
Connection: Close
And after response connection stays open (as would stay with "Connection: keep-alive" header).
Is this a bug or problem in configuration? Is anybody experiencing the same problem?
I think I have a similar issue. My LB is querying Version service but after a while the ESB stops responding and a bunch of connection timeouts are visible in the logs. I think the ESB is not releasing its connections. Must be some configuration option to specify to close connection or timeout after a period.
We have shoutcast/icecast audio streams. I'd like to be able to provide a link such as mobiledroid.php on our web site that will open using default player. I've seen this done on another site so I do know it's possible.
I assume it uses php headers and streams via the php file as a stream?
Using Brad's instructions, the android actually gives the option to open with sound player. Nice one.
It also plays on WMP through PC but not on the android how the above link plays
header("Content-type: audio/mpeg");
header("Transfer-Encoding: chunked");
header("Connection: close");
$sock = fsockopen($streamname,$port); //$streamname is the IP
fputs($sock, "GET $path HTTP/1.0\r\n"); //path in my case is /;stream.mp3
fputs($sock, "Host: $ip\r\n");
fputs($sock, "User-Agent: WinampMPEG/2.8\r\n");
fputs($sock, "Accept: */*\r\n");
fputs($sock, "Icy-MetaData:1\r\n");
fputs($sock, "Connection: close\r\n\r\n");
fpassthru($sock);
fclose($sock);
On the android, it says "Sorry, this player does not support this type of audio file"
Update 2:
Removing "Transfer-Encoding" will play on android but as usual will take a long time to begin stream with "Preparing" status due to a live stream not having "Content-Length"
header("Transfer-Encoding: none"); also removed from above code:
Quoting Brad:
Android 2.3 and later has an issue with Transfer-Encoding set to "none". Removing that hard-set header puts the stream back to chunked Transfer-Encoding. This works great for Android 2.3+. Originally I had disabled chunked encoding as VLC doesn't support it. It also seems that Android 2.2 and older does not support chunked encoding.
Noting here that although it works on android, most live streams will take an awful amount of time to begin.
Problem
Traditionally, you would serve a playlist file which would be saved by your browser, and then opened in whatever player software was configured to open such playlists. The player would then read the URL of the stream, connect to it, and begin streaming.
On Android, they (for some crazy reason) chose not to support playlist files as supported media. Because of this, there is no direct way to launch the player using the traditional method.
Solution
On Android it seems that if you link directly to an MP3 file/stream, instead of downloading the file the default action is to open up a media player and try to stream it. This means that you can easily link directly to the URL of your stream (bypassing the playlist step entirely).
There is a catch... streams served with SHOUTcast aren't exactly HTTP compliant. They are close, but not perfect. The real hangup here seems to be one of content length. Typically, HTTP servers send a Content-Length response header. With streaming media, the length is unknown. There are two ways around the problem:
Use chunked transfer encoding. You can do this by setting the following headers: Transfer-Encoding: chunked Then, use chunked encoding for the stream, and you're good to go.
Use no transfer encoding, and specify that the connection will be closed when the resource is finished transferring, with these headers: Transfer-Encoding: none Connection: close
Your example link uses method one. I'm using method two successfully as well.
Once your server is talking valid HTTP, playback on Android seems to be a breeze.
Implementation
There are a handful of ways to go about implementing this fix. You have mentioned a PHP solution. If cURL won't work, you can always fsockopen() or stream_socket_client() to make a direct TCP connection, and handle the incoming stream data yourself. From there, you simply need to send the correct response headers and relay the data as it comes in. Keep in mind that a PHP instance will be running for each connected client, and each instance will make a connection to your server as well. This isn't ideal, but depending on what you have available, might be the only method for you.