Subject: [hybi] Using JSON instead of HTTP-like headers

From: "Simon Pieters" <[email-masked]>
Date: Wed, 03 Nov 2010 13:38:00 +0100

If we're going to mask the headers with XOR, there's no reason for them to  
be HTTP-like since they won't take part in HTTP infrastructure. In Opera  
we could not reuse our HTTP code to parse the headers since the WebSocket  
spec has different parsing rules for them.

Thus, I think we should consider using JSON to encode the headers. And not  
make it JSON-*like* but actually JSON so we can use the JSON parsing code.  
(The reason the spec doesn't reference HTTP for parsing the headers is  
that HTTP doesn't define error handling and has useless features like  
comments, escapes and continuation lines.)

-- 
Simon Pieters
Opera Software

---

From: Adam Barth <[email-masked]>
Date: Wed, 3 Nov 2010 12:10:27 -0700

Makes sense to me, but I'm a certified JSON fan.

Adam

On Wed, Nov 3, 2010 at 5:38 AM, Simon Pieters <[email-masked]> wrote:
> be HTTP-like since they won't take part in HTTP infrastructure. In Opera we
> could not reuse our HTTP code to parse the headers since the WebSocket spec
> has different parsing rules for them.
>
> (The reason the spec doesn't reference HTTP for parsing the headers is that
> HTTP doesn't define error handling and has useless features like comments,
> escapes and continuation lines.)
>
> --
> Simon Pieters
> Opera Software
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Arman Djusupov <[email-masked]>
Date: Thu, 04 Nov 2010 11:48:58 +0200

Won't this take us a bit too far away from reusing existing HTTP infrastructure? I am not thrilled with the thought of the additional requirement of supporting JSON parsing too.

Arman

On 11/3/2010 9:10 PM, Adam Barth wrote:
> On Wed, Nov 3, 2010 at 5:38 AM, Simon Pieters<[email-masked]>  wrote:

---

From: gustav <[email-masked]>
Date: Thu, 4 Nov 2010 11:37:55 +0100

On 4 November 2010 10:48, Arman Djusupov <[email-masked]> wrote:

> Won't this take us a bit too far away from reusing existing HTTP
> infrastructure? I am not thrilled with the thought of the additional
> requirement of supporting JSON parsing too.
>
> Arman
>
>  Agree, its also the wrong kind of issue to spend time on at the moment or
at all.
Just because JSON is on of those currently hyped technologies that some love
to use as a fancy universal problem solver does not mean its technically
warranted to use at every possible abstraction layer in computer science.

Its also a bit sad to see the extreme interest in making the protocol
complex and just odd due to the assumed incompetence of programmers, where
do you draw an objectively reasonable line ?.
Is it not bad enough that some people regardless of education and experience
are unsuitable as programmers, should they also screw up the protocol
specifications ?.

Its imho technical sound solutions to real technical problems that are
of preferable long term nature that needs to be the current focus.

regards
  gustav

---

From: Micheil Smith <[email-masked]>
Date: Fri, 5 Nov 2010 05:39:48 +1100

I would argue that most of the header parsing that we have to do, we currently have 
to do using custom parsers because of what the websocket protocol expects. That 
said, I know there are JSON libraries for almost every language out there. Given, 
JavaScript engines have it built in, PHP the same, Ruby, Python, C, C++, etc. 

If you have to work with any other modern web service, working with JSON is almost 
a given.

I'm all for having websocket-specific options in the headers.

Yours,
Micheil Smith
--
BrandedCode.com

On 04/11/2010, at 9:37 PM, gustav wrote:

>  Agree, its also the wrong kind of issue to spend time on at the moment or at all.
> Just because JSON is on of those currently hyped technologies that some love to use as a fancy universal problem solver does not mean its technically warranted to use at every possible abstraction layer in computer science.
> 
> Its also a bit sad to see the extreme interest in making the protocol complex and just odd due to the assumed incompetence of programmers, where do you draw an objectively reasonable line ?.
> Is it not bad enough that some people regardless of education and experience are unsuitable as programmers, should they also screw up the protocol specifications ?.
> 
> Its imho technical sound solutions to real technical problems that are of preferable long term nature that needs to be the current focus.
> 
> regards
>   gustav

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 5 Nov 2010 14:16:12 +1100

> has different parsing rules for them.

On the server side, we can't stop our HTTP code from parsing the
request, because
we have to parse them before we know they are websocket handshakes.

> escapes and continuation lines.)

I think it the problem is having the spec specifying different parsing
of HTTP-like headers. It should just reference the specification and
then add a caveat that features like comments, escapes and
continuation lines do not need to be supported.

As it is now, HTTP servers will most likely support these features,
which could be grounds for a websocket test suite to fail those
servers.

cheers

---

From: "Simon Pieters" <[email-masked]>
Date: Fri, 05 Nov 2010 10:21:49 +0100

> we have to parse them before we know they are websocket handshakes.

Sure. But if the headers are masked, the HTTP code isn't going to make any  
sense out of it anyway...

>> that

I wouldn't like that for the client side at least. No defined error  
handling and optional features are bad for interoperability.

> which could be grounds for a websocket test suite to fail those

Right.

-- 
Simon Pieters
Opera Software