Does Server-Sent Events Utilise HTTP/2 Pipelining - server-sent-events

When using SSE through the HTML5 EventSource object, do the requests utilise the HTTP/2 multiplexing / pipelining features? In particular, will SSE requests in different tabs (re)use the same HTTP/2 connection?
I assume so, since SSE is based (AFAIK) on HTTP/1.1 chunked_encoding technology, but wanted to check.

Yes they will. Chrome's http2 tag is a great way to explore how http2 requests are emitted: chrome://net-internals/#http2.
For the requests emitted by SSE, you should see something like:
HTTP2_SESSION_SEND_HEADERS
--> exclusive = true
--> fin = true
--> has_priority = true
--> :method: GET
:authority: h2.example.org
:scheme: https
:path: /demo_sse.php
accept: text/event-stream
cache-control: no-cache
referer: https://h2.example.org/
accept-encoding: gzip, deflate, sdch, br
accept-language: en-US,en;q=0.8,fr;q=0.6,es;q=0.4
--> parent_stream_id = 0
--> priority = 1
--> stream_id = 7
As you can see in this example, the browser sent the request on stream id 7, re-using the connection it had to fetch the html.

Theoretically, yes. And, in practice the answer should be the same, as most browsers have implemented SSE on top of their XmlHttpRequest2 object.
(To be fair, I've not found a definitive reference that says AJAX requests to the same origin are shared across tabs, but it is hard to imagine why a browser would not have allowed that - I've not managed to come up with a security reason, for instance.)

Related

Why I can't receive a live555 RTSP stream into a QVideoWidget?

I am trying to stream a H.264 video stream from a live555 server to a client application that displays it using QVideoWidget on Windows (Qt 5.5)
Unfortunately, the QVideoWidget does not show anything (but it does show videos that start with http:// instead of rtsp://).
If I sniff the packets I can see that the server is returned a 405 Method not allowed:
GET /testStream HTTP/1.0
Host: 172.19.217.147
User-Agent: NSPlayer/12.00.7601.17514
Accept: /
Accept-Language: en-us, *;q=0.1
Connection: Keep-Alive
Pragma: xClientGuid=
{3300AD50-2C39-46C0-AE0A-889398BAE808}
Pragma: packet-pair-experiment=1
Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, com.microsoft.wm.startupprofile, com.microsoft.wm.predstrm
Pragma: no-cache,stream-time=0,stream-offset=0:0,packet-num=4294967295,max-duration=0
Pragma: LinkBW=2147483647, rate=1.000, AccelDuration=10000, AccelBW=2147483647
HTTP/1.1 405 Method Not Allowed
Date: Tue, Oct 06 2015 13:35:55 GMT
I am using live555 testH264VideoStreamer to stream the video.
If I try to use libVLC then it works. Why is it not working with QVideoWidget (which in turn uses Windows Media Foundation)?
It seems that Windows Media Foundation does not support many 3rd party RSTP streams which have slightly different headers and capabilities.
"The MF RTSP source has not been widely tested with third party RTSP servers." https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/4ac87f5f-b8c5-471a-a424-55c0fff04eac/using-the-media-foundation-sdk-to-parse-rtsp-streams?forum=mediafoundationdevelopment
In the context of RTSP, "Media Foundation supports the following formats: WMA, WMV, audio/L16 (LPCM), and audio/MPA (MP3). The server's response should indicate which format it is asking for." https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/e1a970aa-8bf5-46bb-a301-de271a6ae4bc/rtsp-without-proprietary-supported-header?forum=mediafoundationdevelopment
Apparently, a custom WMF media source would need to be implemented and it may have differences depending on the quirks of the RTSP device.

What is a chunked request in OpenTSDB?

I'm using Qt4 to post some data points to a OpenTSDB server, which doesn't supports chunked HTTP requests.
The code is basically this:
QNetworkRequest request(m_url);
request.setHeader(QNetworkRequest::ContentTypeHeader, QString("application/json"));
request.setHeader(QNetworkRequest::ContentLengthHeader, jsonRequest.toAscii().size());
m_networkAccessManager.post(request, jsonRequest.toAscii());
jsonRequest is a QString containing the data points. This code is called from time to time to upload data to the server, and it usually works fine. However, sometimes I receive an error from openTSDB stating that "Chunked request not supported.".
This seems to happen when the request gets a little bigger (and by bigger, I mean some KB of data).
edit:
I've done a tcpdump of the request when the problem arises, and in fact it doesn't seen to be chunked:
POST /api/put HTTP/1.1
Content-Type: application/json
Content-Length: 14073
Connection: Keep-Alive
Accept-Encoding: gzip
Accept-Language: en,*
User-Agent: Mozilla/5.0
Host: 192.168.xx.xxx:xxxx
[{"metric":"slt.reader.temperature","timestamp":1420736269427,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736280628,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736291637,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736302748,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736313840,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736325011,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736336039,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736347182,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736358210,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736369372,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736380401,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736385286,"value":0,"tags":{"sltId":"5036","readerId":"1","antenna":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736385286,"value":10,"tags":{"sltId":"5036","readerId":"1","antenna":"2","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736385286,"value":7,"tags":{"sltId":"5036","readerId":"1","antenna":"3","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736385287,"value":6,"tags":{"sltId":"5036","readerId":"1","antenna":"4","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736385287,"value":13,"tags":{"sltId":"5036","readerId":"1","antenna":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736385287,"value":99,"tags":{"sltId":"5036","readerId":"1","antenna":"2","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736385287,"value":102,"tags":{"sltId":"5036","readerId":"1","antenna":"3","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736385287,"value":93,"tags":{"sltId":"5036","readerId":"1","antenna":"4","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.transactionsNotDeciphered","timestamp":1420736385287,"value":0,"tags":{"sltId":"5036","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736391436,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736402608,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736413642,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736424676,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736435823,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736446850,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736458007,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736469060,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736480207,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736491418,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736502620,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736513638,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736524682,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736535712,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736546742,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736557834,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736568858,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736579932,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736590966,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736601993,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736613183,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736624357,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736635387,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736646414,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736657493,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736668624,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736679743,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736685286,"value":0,"tags":{"sltId":"5036","readerId":"1","antenna":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736685286,"value":8,"tags":{"sltId":"5036","readerId":"1","antenna":"2","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736685286,"value":9,"tags":{"sltId":"5036","readerId":"1","antenna":"3","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736685295,"value":5,"tags":{"sltId":"5036","readerId":"1","antenna":"4","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736685295,"value":4,"tags":{"sltId":"5036","readerId":"1","antenna":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736685295,"value":88,"tags":{"sltId":"5036","readerId":"1","antenna":"2","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736685295,"value":130,"tags":{"sltId":"5036","readerId":"1","antenna":"3","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736685296,"value":123,"tags":{"sltId":"5036","readerId":"1","antenna":"4","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.transactionsNotDeciphered","timestamp":1420736685296,"value":0,"tags":{"sltId":"5036","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736690786,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736701910,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736712968,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736723999,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736735075,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736746106,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736757266,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736768455,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736779473,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736790606,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736801633,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736812713,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736823740,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736834856,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736845958,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736857103,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736868216,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736879292,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736890320,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736901503,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736912608,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736923761,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736934850,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736946033,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736957061,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736968223,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736979256,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736985284,"value":0,"tags":{"sltId":"5036","readerId":"1","antenna":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736985285,"value":16,"tags":{"sltId":"5036","readerId":"1","antenna":"2","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736985285,"value":9,"tags":{"sltId":"5036","readerId":"1","antenna":"3","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tags_read","timestamp":1420736985285,"value":11,"tags":{"sltId":"5036","readerId":"1","antenna":"4","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736985285,"value":9,"tags":{"sltId":"5036","readerId":"1","antenna":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736985285,"value":162,"tags":{"sltId":"5036","readerId":"1","antenna":"2","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736985285,"value":166,"tags":{"sltId":"5036","readerId":"1","antenna":"3","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.tag_transactions","timestamp":1420736985285,"value":157,"tags":{"sltId":"5036","readerId":"1","antenna":"4","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.transactionsNotDeciphered","timestamp":1420736985286,"value":0,"tags":{"sltId":"5036","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420736990353,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420737001532,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420737012658,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420737023691,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420737034823,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420737045906,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420737056942,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}},{"metric":"slt.reader.temperature","timestamp":1420737068032,"value":56,"tags":{"sltId":"5036","readerId":"1","host":"xxxxxxxxxxxxxxxxx"}}]HTTP/1.1 400 Bad Request
Content-Length: 1080
Content-Type: text/html; charset=UTF-8
Date: Thu, 08 Jan 2015 17:18:43 GMT
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta http-equiv=content-type content="text/html;charset=utf-8"><title>Bad Request</title>
<style><!--
body{font-family:arial,sans-serif;margin-left:2em}A.l:link{color:#6f6f6f}A.u:link{color:green}.subg{background-color:#e2f4f7}.fwf{font-family:monospace;white-space:pre-wrap}//--></style></head>
<body text=#000000 bgcolor=#ffffff><table border=0 cellpadding=2 cellspacing=0 width=100%><tr><td rowspan=3 width=1% nowrap><b><font color=#c71a32 size=10>T</font><font color=#00a189 size=10>S</font><font color=#1a65b7 size=10>D</font> </b><td> </td></tr><tr><td class=subg><font color=#507e9b><b>Looks like it's your fault this time</b></td></tr><tr><td> </td></tr></table><blockquote><h1>Bad Request</h1>Sorry but your request was rejected as being invalid.<br/><br/>The reason provided was:<blockquote>Chunked request not supported.</blockquote></blockquote><table width=100% cellpadding=0 cellspacing=0><tr><td class=subg><img alt="" width=1 height=6></td></tr></table></body></html>
I was thinking Qt was changing to use a chunked request when the request got larger, but it's not the case. So the current question is: what is a chunked request in openTSDB?
I've finally found the reason it thinks my request is chunked: OpenTSDB internally uses Netty for networking, and if Netty reads a block that doesn't contain the complete request, then it's flagged as chunked, even if there's no Transfer-Encoding header in the request.
There are two possible solutions for this:
adding "tsd.http.request.enable_chunked = true" to the config file, so that it doesn't reject chunked requests and adding "tsd.http.request.max_chunk = " to the config file, and setting it to a sensible size for your requests
If you can change the client, force it to send smaller requests
Please note that enabling chunked requests for public facing servers may not be a good idea, as a malicious client can send unbounded requests, overloading the server.
Credits goes to irc users jaylr and manolama, who provided me the info on irc channel #opentsdb#freenode.net

How to get the response content of an HTTP 404 response

Is there an easier way of getting the content of an HTTP 404 response than directly accessing the host via tcp?
This is a sample of a 404 response with content:
HTTP/1.1 404 Object Not Found
Server: CouchDB/1.3.0 (Erlang OTP/R15B03)
Date: Wed, 24 Jul 2013 08:32:50 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 41
Cache-Control: must-revalidate
{"error":"not_found","reason":"missing"}
The Rebol HTTP scheme really isn't designed with this in mind, it's geared toward reading content the way you would in a browser, not services over HTTP.
In saying that, you can hack the protocol to subvert how Rebol 2 handles different response codes:
in-http-scheme: func [does [block!]][
do bind :does bind? last body-of get in system/schemes/http/handler 'open
]
in-http-scheme [
remove-each [code response] response-actions [find [400 403 404] code]
append response-actions [400 success 403 success 404 success]
]
The caveat here is that the HTTP protocol has to have been initiated (any http port opened/read). response-actions can still be accessed when http has not been initiated:
select body-of get in system/schemes/http/handler 'open quote response-actions:
You can get the last response line thus:
in-http-scheme [response-line]
Alternatively you are going to need a scheme designed for services over HTTP. I have a REST protocol (two versions, one that uses cURL, and one that uses a customised HTTP scheme that works, but isn't as good). Though are for Rebol 2. I have plans for a Rebol 3 version.
Christopher Ross-Gill has created a REST protocol for Rebol which allows simple access to all headers and even handles OAuth. Have a look at the details here.
http://www.ross-gill.com/page/REST_Protocol
Unfortunately it is only for Rebol 2 at the moment and it depends on the use of curl for the http requests.

Is this HTTP Header wrong?

I am trying to write a torrent downloader and needed to work out how to contact a tracker. I used the Fiddler2 program to intercept a tracker request sent from Vuze to it's tracker.
In the message sent (shown below), the Connection header is declared twice with different values.
Is this a correct use of the Connection header?
What does Connection: keep-alive do?
GET /announce?info_hash=0Z%22...&azver=3&azas=12576 HTTP/1.1
User-Agent: Azureus 4.7.0.2;Windows 7;Java 1.6.0_31
Connection: close
Accept-Encoding: gzip
Host: tracker.update.vuze.com:6969
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
From RFC2616 section 4.2:
Multiple message-header fields with the same field-name MAY be present
in a message if and only if the entire field-value for that header
field is defined as a comma-separated list [i.e., #(values)]. It MUST
be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the interpretation
of the combined field value, and thus a proxy MUST NOT change the
order of these field values when a message is forwarded.
Edit:
According to section 14.10, Connection is such a field-name, so having multiple Connection headers is technically correct.
From 14.10 the grammar production for the Connection header is Connection = "Connection" ":" 1#(connection-token), so one or more comma separated tokens are valid.
In practise however, it may be that the second Connection header will be ignored, and thus the web server will expect to close the underlying TCP connection once the response has been sent.
For HTTP 1.1 the default mode is for the server to keep the underlying TCP connection open for subsequent requests, although many servers will limit the total number of requests made before closing the connection anyway.
HTTP 1.1 allows multiple Connection headers. The semantics of multiple such headers are defined to be the same as a single header with all values joined together with commas, e.g.
Connection: close
Connection: keep-alive
is the same as:
Connection: close,keep-alive
So technically, these headers are fine. However, I will herewith predict without having made some experiments that there will be a lot of servers out there (especially not so well tested ones such as torrent trackers) who will ignore either one of these headers.
Now, the deeper problem is that "keep-alive" is some http 1.0 extension, and kind of contradicts the "close", so I guess this combination is simply a bug in the torrent client. I guess most trackers will not allow persistent connections anyway, though, so I think the bets way to proceed i to only have a single "Connection: close" header.
Its weird to have 2 Connection Header Fields. I think you can only expect a non-deterministic behavior as the handling of this case depends solely on the implementation of the web server.
It might end up with any of the 2 in (let's say) the hashmap storing the fields.
Basically, keep alive means that the browser is allowed to maintain the connection to the server and to keep retrieving images, scripts over it. Usually this is not the case. Normally, a Connection to a web server is closed after the request was given a response.
Connection: Close
means that after the the request has completed close the connection.
Connection: keep-alive
means keep the connection open for future request.
You should only have one Connection parameter.
So therefore the HTTP header is not correct.

HTTP Packets, Whats Happening?

basically, i was wiresharking packets on my PS3 while viewing Motorstorm Leaderboards. The leaderboards are sent to my ps3 in XML format but only after i have been authorised. So can someone please tell me what is happening between these three packets and how i could replicate it in a browser?
Packet 1 From my PS3 to Sony Servers
POST /ranking_view/func/get_player_rank HTTP/1.1
Host: ranking-view-a01.u0.np.community.playstation.net
Connection: Keep-Alive
Content-Length: 213
Authorization: Digest username="c7y-ranking01", realm="c7y-ranking", nonce="2SpsV4WABAA=47a2b36030cd94de1190f6b9f05db1bd5584bc2a", uri="/ranking_view/func/get_player_rank", qop="auth", nc="00000001", cnonce="d4eb1eb60ab4efaea1476869d83a6e0b", response="96b55c6e79f84dd41b46eb66bed1c167"
Accept-Encoding: identity
User-Agent: PS3Community-agent/1.0.0 libhttp/1.0.0
<?xml version="1.0" encoding="utf-8"?><ranking platform="ps3" sv="3.15"><titleid>NPWR00012_00</titleid><board>7</board><jid>Panzerborn#a5.gb.np.playstation.net</jid><option message="false" info="false"/></ranking>
Packet 2 Sony Server Response to my PS3
Date: Fri, 26 Feb 2010 19:06:12 GMT
WWW-Authenticate: Digest realm="c7y-ranking", nonce="a3PFl4WABAA=6d375259676ec79641448a8032a795b8e12ccae4", algorithm=MD5, stale=true, qop="auth"
Content-Length: 401
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Authorization Required</title>
</head><body>
<h1>Authorization Required</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body></html>
Packet 3 PS3 response to Sony Servers last packet
POST /ranking_view/func/get_player_rank HTTP/1.1
Host: ranking-view-a01.u0.np.community.playstation.net
Connection: Keep-Alive
Authorization: Digest username="c7y-ranking01", realm="c7y-ranking", nonce="a3PFl4WABAA=6d375259676ec79641448a8032a795b8e12ccae4", uri="/ranking_view/func/get_player_rank", qop="auth", nc="00000001", cnonce="58869490a891002d8c56573496274a3a", response="ca3d6f252d4e398b8f751c201a3f8f08"
Accept-Encoding: identity
User-Agent: PS3Community-agent/1.0.0 libhttp/1.0.0
<?xml version="1.0" encoding="utf-8"?><ranking platform="ps3" sv="3.15"><titleid>NPWR00012_00</titleid><board>7</board><jid>Panzerborn#a5.gb.np.playstation.net</jid><option message="false" info="false"/></ranking>
I tried to replicate this in Firefox and tamper headers as well as in PHP cURL but im getting nowhere. I assume it is to do with the nonce, cnonce and responce variables that keep changing >< please help =)
Nonce, cnonce and so on are related to HTTP Digest Authentication, which is an authentication mechanism that enables authentication without sending a password in plain text. So if you want to cheat in your PS3 game, you'll first have to hack that password out of the MD5 hash, I guess.
And it's not called HTTP packets, on layer 7 you would usually say request/response or similar.
The nonce an nonce and cnonce look like hash codes.
One possible defense mechanism against cheaters could be this:
def ps3client_send_score():
score = "bazillion points"
nonce = md5(score + "something you don't know about")
send_to_server(score, nonce)
On the server side:
def get_client_score(score, nonce):
if md5(score+"something you don't know about")==nonce:
accept_score(score)
else:
reject_score_and_ban_the_fool_if_he_continues_this()
So unless you want to spend weeks trying to find the salt deep in your game, forget it.

Resources