Bad RFC implementation on HTTP protocol

[sbs4000]

Hello,

I happen to have a Boom on a wireless lan talking to a SBC on a LAN with a router between. The router is an enterprise class IDS (intrusion detection system) and blocks the communication because of a wrong implementation of the HTTP protocol. I have to configure a specific bypass to make it work.

Here is what happens:

When I press play on the boom, the following request in sent to the SBC:

GET /stream.mp3?player=00:04:20:1e:90:ca HTTP/1.0

This is fine. But then, 3 LF (line feed) are following which does not conform RFC 1945 that says that it should be CR/LF only.

Second, a GET is not allowed to carry a payload. But the third LF is interpreted as a payload (the 2 first two are ok: end of command, end of HTTP header).

So I guess this message is to the engineers: could you make the changes for a next version to conform the the RFC?

Best regards

[peterw]

You mean from the SBC, right?

Please file a bug at bugs.slimdevices.com.

[sbs4000]

Sorry, I meant SC (SqueezeCenter). The request is sent from the Boom to the SqueezeCenter (7.3.2)

Best regards

[dean]

Thanks for the report. Could you file a bug on bugs.slimdevices.com?
Thanks!

-dean


On Mar 14, 2009, at 2:50 AM, sbs4000 wrote:

>
> Hello,
>
> I happen to have a Boom on a wireless lan talking to a SBC on a LAN
> with a router between. The router is an enterprise class IDS
> (intrusion
> detection system) and blocks the communication because of a wrong
> implementation of the HTTP protocol. I have to configure a specific
> bypass to make it work.
>
> Here is what happens:
>
> When I press play on the boom, the following request in sent to the
> SBC:
>
> GET /stream.mp3?player=00:04:20:1e:90:ca HTTP/1.0
>
> This is fine. But then, 3 LF (line feed) are following which does not
> conform RFC 1945 that says that it should be CR/LF only.
>
> Second, a GET is not allowed to carry a payload. But the third LF is
> interpreted as a payload (the 2 first two are ok: end of command, end
> of HTTP header).
>
> So I guess this message is to the engineers: could you make the
> changes
> for a next version to conform the the RFC?
>
> Best regards
>
>
> --
> sbs4000
> ------------------------------------------------------------------------
> sbs4000's Profile: http://forums.slimdevices.com/member.php?userid=22214
> View this thread: http://forums.slimdevices.com/showthread.php?t=61329
>
>

[sbs4000]

I have filed a bug.

[andyg]

Heh, thanks, that request is really wrong:

$request_string = sprintf("GET /stream.mp3?player=%s HTTP/1.0\n",
$client->id);
$request_string .= "\n";
if (length($request_string) % 2) {
$request_string .= "\n";
}

No idea what the last one is supposed to do! And they should be CRLF.

Will fix.

On Mar 14, 2009, at 7:13 AM, dean blackketter wrote:

> Thanks for the report. Could you file a bug on bugs.slimdevices.com?
> Thanks!
>
> -dean
>
>
> On Mar 14, 2009, at 2:50 AM, sbs4000 wrote:
>
>>
>> Hello,
>>
>> I happen to have a Boom on a wireless lan talking to a SBC on a LAN
>> with a router between. The router is an enterprise class IDS
>> (intrusion
>> detection system) and blocks the communication because of a wrong
>> implementation of the HTTP protocol. I have to configure a specific
>> bypass to make it work.
>>
>> Here is what happens:
>>
>> When I press play on the boom, the following request in sent to the
>> SBC:
>>
>> GET /stream.mp3?player=00:04:20:1e:90:ca HTTP/1.0
>>
>> This is fine. But then, 3 LF (line feed) are following which does not
>> conform RFC 1945 that says that it should be CR/LF only.
>>
>> Second, a GET is not allowed to carry a payload. But the third LF is
>> interpreted as a payload (the 2 first two are ok: end of command, end
>> of HTTP header).
>>
>> So I guess this message is to the engineers: could you make the
>> changes
>> for a next version to conform the the RFC?
>>
>> Best regards