node-spdy + chrome canary problems

[Fedor Indutny]

Hello, devs!

I'm developing new node-spdy ( https://github.com/indutny/node-spdy ) module for node.js

And while it works fine with both Firefox nightly and chrome stable, it makes my server throwing EPIPE error.

Can you please help me investigating this problem?

Url of my server: https://spdy-twitlog.indutny.com/

This page is private now, so please don't post tweets or anything!

Thanks,

Fedor.

[Fedor Indutny]

Ok, EPIPE is understood.

Attaching a dump here and a line from canary's log:

[811:23811:3422534379121:VERBOSE1:spdy_session.cc(910)] ABANDONED (stream_id=1): /

Cheers,

Fedor.

[Fedor Indutny]

Looks like I finally found what problem was in...

If I send SYN_REPLY in separate chunks (i.e. header + zlib chunks ) browser will fail to recognize it.

Is that how things supposed to work?

Cheers,

Fedor.

[Mike Belshe]

On Sun, Jan 8, 2012 at 10:14 PM, Fedor Indutny <fe...@indutny.com> wrote:

Looks like I finally found what problem was in...

If I send SYN_REPLY in separate chunks (i.e. header + zlib chunks ) browser will fail to recognize it.

Sounds like a bug!  Do you have an easy test case?

Mike

[Fedor Indutny]

I'll write one tomorrow!

But if you want to test now - just split one SYN_REPLY frame into multiple TCP frames (like spdy frame header and body) and send them in answer to canary's SYN_STREAM.

Cheers,

Fedor.

[Roberto Peon]

Fedor--

Is that in two separate sends(), or something else?

-=R

[Roberto Peon]

That answers the question, thanks :)

That does seem like a "new" bug.

-=R

[Fedor Indutny]

Actually,

I think it's two separate sends, but I thought that would result in two TCP frames (at least sometimes?)

Cheers,

Fedor.

[Roberto Peon]

Not always, but if you have Nagle turned off, it is certainly more likely!

[Fedor Indutny]

No, it wasn't.... I'm using 18.0.1001.1 canary

So take a SYN_REPLY frame and split it into two chunks [0...14] and [14...], send them separately and browser will fail.

Chunk size not really matters here, just chop it.

Cheers,

Fedor.

On Tue, Jan 10, 2012 at 5:40 AM, Raman Tenneti <rten...@google.com> wrote:

We had recently implemented handling of chunked control frame headers (SYN_STREAN, SYN_REPLY and HEADERS). It was deployed in chrome18.0.1000.0.

If you are not using Chrome 18, is it possible to see if it still happens with M18. 

We are working on one known bug with ProcessInput if we process1 byte at a time (chunk size is 1). Wanted to verify that it is related to that bug.

M18 can be downloaded from http://tools.google.com/dlpage/chromesxs 

thanks very much,

raman

[Raman Tenneti]

Hi Fedor,
Thanks for the following report.

The following is the bug

http://code.google.com/p/chromium/issues/detail?id=108596

Will be committing the following CL to fix the above problem asap
(thanks to Antonio Vicente, Jim Roskind and Wan-Teh)

http://codereview.chromium.org/9185036/

thanks very much,
raman

On Jan 9, 8:54 pm, Fedor Indutny <fe...@indutny.com> wrote:
> No, it wasn't.... I'm using 18.0.1001.1 canary
>
> So take a SYN_REPLY frame and split it into two chunks [0...14] and
> [14...], send them separately and browser will fail.
> Chunk size not really matters here, just chop it.
>
> Cheers,
> Fedor.
>
>
>
>
>
>
>
> On Tue, Jan 10, 2012 at 5:40 AM, Raman Tenneti <rtenn...@google.com> wrote:
> > We had recently implemented handling of chunked control frame headers
> > (SYN_STREAN, SYN_REPLY and HEADERS). It was deployed in chrome18.0.1000.0.
>
> > If you are not using Chrome 18, is it possible to see if it still happens
> > with M18.
>
> > We are working on one known bug with ProcessInput if we process1 byte at a
> > time (chunk size is 1). Wanted to verify that it is related to that bug.
>

> > M18 can be downloaded fromhttp://tools.google.com/dlpage/chromesxs

>
> > thanks very much,
> > raman
>
> > On Mon, Jan 9, 2012 at 1:30 PM, Roberto Peon <fe...@google.com> wrote:
>
> >> Not always, but if you have Nagle turned off, it is certainly more likely!
>
> >> On Mon, Jan 9, 2012 at 1:25 PM, Fedor Indutny <fe...@indutny.com> wrote:
>
> >>> Actually,
>
> >>> I think it's two separate sends, but I thought that would result in two
> >>> TCP frames (at least sometimes?)
>
> >>> Cheers,
> >>> Fedor.
>
> >>> On Tue, Jan 10, 2012 at 3:04 AM, Roberto Peon <fe...@google.com> wrote:
>
> >>>> That answers the question, thanks :)
> >>>> That does seem like a "new" bug.
> >>>> -=R
>
> >>>> On Mon, Jan 9, 2012 at 1:03 PM, Fedor Indutny <fe...@indutny.com>wrote:
>
> >>>>> I'll write one tomorrow!
>
> >>>>> But if you want to test now - just split one SYN_REPLY frame into
> >>>>> multiple TCP frames (like spdy frame header and body) and send them in
> >>>>> answer to canary's SYN_STREAM.
>
> >>>>> Cheers,
> >>>>> Fedor.
>

> >>>>> On Tue, Jan 10, 2012 at 2:50 AM, Mike Belshe <mbel...@chromium.org>wrote:
>
> >>>>>> On Sun, Jan 8, 2012 at 10:14 PM, Fedor Indutny <fe...@indutny.com>wrote:
>
> >>>>>>> Looks like I finally found what problem was in...
>
> >>>>>>> If I send SYN_REPLY in separate chunks (i.e. header + zlib chunks )
> >>>>>>> browser will fail to recognize it.
>
> >>>>>> Sounds like a bug!  Do you have an easy test case?
>
> >>>>>> Mike
>
> >>>>>>> Is that how things supposed to work?
>
> >>>>>>> Cheers,
> >>>>>>> Fedor.
>
> >>>>>>> On Mon, Jan 9, 2012 at 12:05 PM, Fedor Indutny <fe...@indutny.com>wrote:
>
> >>>>>>>> Ok, EPIPE is understood.
>
> >>>>>>>> Attaching a dump here and a line from canary's log:
>
> >>>>>>>> [811:23811:3422534379121:VERBOSE1:spdy_session.cc(910)] ABANDONED
> >>>>>>>> (stream_id=1): /
>
> >>>>>>>> Cheers,
> >>>>>>>> Fedor.
>
> >>>>>>>> On Sun, Jan 8, 2012 at 8:49 PM, Fedor Indutny <fe...@indutny.com>wrote:
>
> >>>>>>>>> Hello, devs!
>
> >>>>>>>>> I'm developing new node-spdy (

> >>>>>>>>>https://github.com/indutny/node-spdy) module for node.js

[Fedor Indutny]

Thank you!

Cheers,

Fedor.