Re: [hybi] Masking only Payload/Extension Data

[David Endicott <[e-mail]>]

Afterthought:  an unmasked header would allow Websocket aware
intermediaries to manipulate frames without unmasking them.
Websocket aware load balancers and distributed frameworks come to
mind.


On Thu, Mar 10, 2011 at 2:29 PM, David Endicott <[e-mail]> wrote:
> Fair point.  I agree it is not an undue burden given that we already
> have to deal with variable sized length fields anyway.
>
> Upon reflection, I change my vote to: don't care.    I cannot see an
> obvious benefit or drawback to either implementation.
>
>
>
> On Thu, Mar 10, 2011 at 2:13 PM, John Tamplin <[e-mail]> wrote:
>> On Thu, Mar 10, 2011 at 2:08 PM, David Endicott <[e-mail]> wrote:
>>>
>>> It would seem to me that it must go after the length field, or else
>>> how does the server know how much of the following stream to unmask.
>>> It would need to unmask enough of the header to determine the entire
>>> frame size and then continue.  That seems an unnecessary burden and
>>> complicates server reception processing.
>>
>> I'm not sure I understand your objection.  If you are writing a blocking
>> implementation, in the unmasked case you are going to read 2 bytes, and then
>> look at the second byte to decide how many more bytes are in the header.
>>  That lets you determine the length of the frame and read the rest of it.
>>  In the masked case, (as implemented in -06) you will read 6 bytes, then
>> start applying the mask to the bytes read as you process them.  In the
>> non-blocking case, you will have a state machine keeping track of where you
>> are, and as you receive a byte after you have processed the mask you unmask
>> it and process it.  I don't see that it adds much complexity.
>>
>> --
>> John A. Tamplin
>> Software Engineer (GWT), Google
>>
>