Remarks on SPDY specification

[Alexey Shamrin]

Hello!

I came into a few issues while reading current SPDY specification [1].

== Section 2.6.4, SETTINGS [2] ==

"5 - SETTINGS_CURRENT_CWND allows the sender to inform the
remote endpoint of the current CWND value."

It's not clear what is CWND. Is it TCP CWND? Is it data transfer window
that is described in 2.6.8? (see also next issue)

== Section 2.6.8, WINDOW_UPDATE [3] ==

"An endpoint can use the SETTINGS control frame to adjust the initial
window size for the connection."

Does it assume SETTINGS_CURRENT_CWND? Please clarify.

== Section 2.6.9, Name/Value Header Block [4] ==

"A header name can either be empty (e.g. the length is zero) or it can
contain multiple, NUL-separated values, each with length greater than zero."

I think it must be "header value", not "header name".

P.S. In other aspects SPDY spec is readable and easy to understand.
Thank you!

[1]: http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml
[2]: http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#SETTINGS
[3]: http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#WINDOW_UPDATE
[4]: http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#HeaderBlock

[Alexey Shamrin]

Follow-up remarks:

== Section 3.3.2, Server Push - Client implementation [1] ==

"When a client receives a SYN_STREAM from the server without an 'url'
in the Name/Value section, it must reply with a RST_STREAM with error
code HTTP_PROTOCOL_ERROR."

The sentence above contradicts section 3.3.1 (Server implementation),
which specify no headers for SYN_STREAM from the server. It only
specifies the subsequent HEADERS frame:

"The SYN_STREAM is followed by a HEADERS frame which MUST include a
header for ":scheme", ":host", ":path", which represent the URL for
the resource being pushed."

In addition I haven't found anything about HTTP 'url' header.

== Section 4.6, Design - Unidirectional streams [2] ==

"If the recipient of a stream doesn't with to send data on a stream,"

I think it should be "doesn't wish".

[1]: http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#rfc.section.3.3.2
[2]: http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#rfc.section.4.6

[William Chan (陈智昌)]

On Sat, Nov 26, 2011 at 6:24 AM, Alexey Shamrin <sha...@gmail.com> wrote:

Hello!

I came into a few issues while reading current SPDY specification [1].

== Section 2.6.4, SETTINGS [2] ==

"5 - SETTINGS_CURRENT_CWND allows the sender to inform the
remote endpoint of the current CWND value."

It's not clear what is CWND. Is it TCP CWND? Is it data transfer window
that is described in 2.6.8? (see also next issue)

TCP's CWND

== Section 2.6.8, WINDOW_UPDATE [3] ==

"An endpoint can use the SETTINGS control frame to adjust the initial
window size for the connection."

Does it assume SETTINGS_CURRENT_CWND? Please clarify.

Thanks for asking this question. We're actually planning on defining a new SETTINGS_INITIAL_WINDOW_SIZE setting. I'll add it into the spec.

 

== Section 2.6.9, Name/Value Header Block [4] ==

"A header name can either be empty (e.g. the length is zero) or it can
contain multiple, NUL-separated values, each with length greater than zero."

I think it must be "header value", not "header name".

Yes, you're right. Thanks for the report, I'll fix this.

[William Chan (陈智昌)]

https://github.com/willchan/SPDY-Specification/commit/fc7593d8718693f73d1f164f10ba02c7c13d07c9 has the commit. If people are cool with it, I'll merge it into mbelshe's repo.

[William Chan (陈智昌)]

On Sat, Nov 26, 2011 at 2:16 PM, Alexey Shamrin <sha...@gmail.com> wrote:

Follow-up remarks:

== Section 3.3.2, Server Push - Client implementation [1] ==

"When a client receives a SYN_STREAM from the server without an 'url'
in the Name/Value section, it must reply with a RST_STREAM with error
code HTTP_PROTOCOL_ERROR."

The sentence above contradicts section 3.3.1 (Server implementation),
which specify no headers for SYN_STREAM from the server. It only
specifies the subsequent HEADERS frame:

"The SYN_STREAM is followed by a HEADERS frame which MUST include a
header for ":scheme", ":host", ":path", which represent the URL for
the resource being pushed."

In addition I haven't found anything about HTTP 'url' header.

We used to use the 'url' header. We deprecated it due to many HTTP implementations having difficulty with fully qualified URLs. Instead, we use 'scheme', 'host', and 'path' to uniquely identify a resource. I will fix this error. And the line in 3.3.1 is misleading. It is the server SYN_STREAM which must uniquely identify the resource, by providing 'scheme', 'host', and 'path'. Then all other response headers follow in the subsequent HEADERS frame. I will try to clarify the wording here.

 

== Section 4.6, Design - Unidirectional streams [2] ==

"If the recipient of a stream doesn't with to send data on a stream,"

I think it should be "doesn't wish".

Quite so. Thanks for the report.

[Peter Saint-Andre]

On 11/29/11 6:54 PM, William Chan (陈智昌) wrote:

> We used to use the 'url' header. We deprecated it due to many HTTP
> implementations having difficulty with fully qualified URLs. Instead, we
> use 'scheme', 'host', and 'path' to uniquely identify a resource. I will
> fix this error. And the line in 3.3.1 is misleading. It is the server
> SYN_STREAM which must uniquely identify the resource, by providing
> 'scheme', 'host', and 'path'. Then all other response headers follow in
> the subsequent HEADERS frame. I will try to clarify the wording here.

Speaking of which, please change the [ORIGIN] citation so that it points
to https://datatracker.ietf.org/doc/draft-ietf-websec-origin/ (or just
wait a few days for it to be RFC 6454).

Peter

--
Peter Saint-Andre
https://stpeter.im/

[William Chan (陈智昌)]

https://github.com/willchan/SPDY-Specification/commit/98274eebbb14f98d34a641265752601c22419d97

http://willchan.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml has both commits.

[Philippe Verdy]

2011/11/30 Peter Saint-Andre <stp...@stpeter.im>:

> On 11/29/11 6:54 PM, William Chan (陈智昌) wrote:
>
>> We used to use the 'url' header. We deprecated it due to many HTTP
>> implementations having difficulty with fully qualified URLs. Instead, we
>> use 'scheme', 'host', and 'path' to uniquely identify a resource. I will
>> fix this error. And the line in 3.3.1 is misleading. It is the server
>> SYN_STREAM which must uniquely identify the resource, by providing
>> 'scheme', 'host', and 'path'. Then all other response headers follow in
>> the subsequent HEADERS frame. I will try to clarify the wording here.
>

A full URL may need to specify a query string (after "?"), which is
needed to identify the resource to return or give it parameters. Why
isn't the "query" part not here? Do you imply that the query string
must be within the "path" ? It would contradict the URI
specifications.

There is also sometimes a user string after the scheme and before the
host part (just before "@"), is it intended to be within the "host"
parameter ?

Finally, what about the optional port number that may follow (after
":") the host (domain name or IPv4 address or
[bracketed:IPv6:address]). As the URI scheme may specify an implicit
default port number, it may or may not be present. In a classical HTTP
implementation this does not make any difference if the default port
number is explicitly present or not. But if the "host" part is signed
and checked, what would happen to the "host" validation if the checked
host name in the URL include the port number but not the "host" part,
or the reverse ?

Also some paths may include an access string (before ";") before each
path element. Here again, it should be part of the "path", but the
presence of a ";" would require putting the path value between
quotation marks to avoid splitting the header into multiple
NUL-separated values (note that the last path element may be empty, so
we cannot split it into multiple values without breaking the rule
about accepted values, as there cannot be any empty string in them,
only a single empty value is accepted per header, without any NUL
separation)

Note that there may also be a "fragment" part (after "#"), but it is
not sent to the server but used only by the client, so this should
evidently not be checked. The way how the fragment will be used is
ressource-dependant, not protocol-dependant, and it is left to the
client to interpret it (it's not necessarily an HTML ID, it may
include various data used by the client, for example that will be read
and interpreted used by a javascript running from an HTML page;
changing the "fragment" string should not imply any reload of the
resource and should not change the DOM of the document, but will only
alter the query object with which the resource is referenced and
loaded).

[Roberto Peon]

The scheme, and host are often separated from the rest of the parts of what would be the URL in HTTP requests.
In this case, path or query refers to everything neither host nor scheme.

-=R

[Ryan Hamilton]

Would it be accurate to characterize the value of the spdy "host" header as everything after "://" and before "/", and the value of the "path" header as everything after and including the initial "/"?

[Roberto Peon]

Yup. That's it exactly.

[Philippe Verdy]

Everything ? hmmm... no. Not the fragment (after "#").

And you did not reply to the concern about what is checked in the
"host" part if it's not canonical, and if it interacts with the scheme
(notably the default port number).

This should be addressed to be more precise, notably in terms of
canonicalisation, if these parts must be signed (like in MIME headers
of emails, when using several antispam schemes for authenticating the
sender), to make sure that they are really equivalent, or not. This is
important to make SPDY also secure throught proxies, against
man-in-the-middle attacks (either to inject content, or to replay it).
For supporting HTTPS, this should be a must, notably when SPDY will
multiplex many connections, possibly from multiple sessions with
distinct originating clients or distinct final targets.

2011/11/30 Roberto Peon <fe...@google.com>:

[William Chan (陈智昌)]

Time's up, I'm committing this guy.

[William Chan (陈智昌)]

Is it RFC 6454 yet? Let me know and I'll update the citation.

[William Chan (陈智昌)]

I'm committing this guy too.

[William Chan (陈智昌)]

We welcome patches for more accurate wording. Or submit a reworded section and I'll make the patch myself.

[Peter Saint-Andre]

Not quite. I'll post to this list once it's published.

[William Chan (陈智昌)]

Great, thanks!

[Roberto Peon]

The most accurate thing to say so far is that:

1) the 'host' part is what would show up in the 'host' header of an HTTP/1.1 request

2) the 'url' part is what would show up as the second string on the first line of a request

this could have scheme,host,port, etc., or it could just start with the path and have all the elements from there to the right.

We've seen both (and the HTTP/1.1 spec implies either could happen), and this is the best way to remain as compatible as possible with HTTP/1.1 servers on the backed for those who use a SPDY<->HTTP gateway.

3) the scheme is whatever string would have been used (if not using SPDY) to select the port

Do you have suggestions on how you'd phrase that?
-=R

On Wed, Nov 30, 2011 at 9:40 AM, Philippe Verdy <ver...@wanadoo.fr> wrote:

[Peter Saint-Andre]

Published:

https://datatracker.ietf.org/doc/rfc6454/

[William Chan (陈智昌)]

Thanks Peter.

https://github.com/willchan/SPDY-Specification/commit/965708be7231dc60908215913f86d43454dda0ca has the commit. Assuming it's OK with you, I will push to the main repo soon.

[Peter Saint-Andre]

What's the exact XML for the entire reference? It's not in the
changelog, but it should be:

<reference anchor='RFC6454'>
<front>
<title>The Web Origin Concept</title>
<author initials='A.' surname='Barth' fullname='A. Barth'>
<organization /></author>
<date year='2011' month='December' />
<abstract>
<t>This document defines the concept of an "origin", which is often used
as the scope of authority or privilege by user agents. Typically, user
agents isolate content retrieved from different origins to prevent
malicious web site operators from interfering with the operation of
benign web sites. In addition to outlining the principles that underlie
the concept of origin, this document details how to determine the origin
of a URI and how to serialize an origin into a string. It also defines
an HTTP header field, named "Origin", that indicates which origins are
associated with an HTTP request. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='6454' />
<format type='TXT' octets='41363'
target='http://www.rfc-editor.org/rfc/rfc6454.txt' />
</reference>

On 12/13/11 5:09 PM, William Chan (陈智昌) wrote:
> Thanks Peter.
>
> https://github.com/willchan/SPDY-Specification/commit/965708be7231dc60908215913f86d43454dda0ca
> has the commit. Assuming it's OK with you, I will push to the main repo
> soon.
>
> On Tue, Dec 13, 2011 at 2:47 PM, Peter Saint-Andre <stp...@stpeter.im
> <mailto:stp...@stpeter.im>> wrote:
>
> Published:
>
> https://datatracker.ietf.org/doc/rfc6454/
>
> On 12/5/11 7:34 PM, Peter Saint-Andre wrote:
> > Not quite. I'll post to this list once it's published.
> >
> > On 12/5/11 7:21 PM, William Chan (陈智昌) wrote:
> >> Is it RFC 6454 yet? Let me know and I'll update the citation.
> >>
> >> On Tue, Nov 29, 2011 at 6:05 PM, Peter Saint-Andre
> <stp...@stpeter.im <mailto:stp...@stpeter.im>

[William Chan (陈智昌)]

Not sure if I'm parsing your question properly, but the treeish only contains the diff. If you want to see the full XML document, please refer to https://github.com/willchan/SPDY-Specification/blob/965708be7231dc60908215913f86d43454dda0ca/draft-mbelshe-spdy-00.xml.

I'll update the document as you indicated shortly.

[Peter Saint-Andre]

Ah, I see, you are using homegrown references. For your purposes here,
that's just fine. However, just so you know, the official XML snippets
for RFCs, Internet-Drafts, W3C specs, etc., can be found here:

http://xml.resource.org/

Enjoy! ;-)

[William Chan (陈智昌)]

I won't bother changing this yet then. I'll let Mike do the cleanup sweep later in bulk. Pushing to Mike's repo now instead.

[Peter Saint-Andre]

Sure. I'll send a patch if I can find the time.

On 12/14/11 12:15 PM, William Chan (陈智昌) wrote:
> I won't bother changing this yet then. I'll let Mike do the cleanup
> sweep later in bulk. Pushing to Mike's repo now instead.
>
> On Wed, Dec 14, 2011 at 11:13 AM, Peter Saint-Andre <stp...@stpeter.im
> <mailto:stp...@stpeter.im>> wrote:
>
> Ah, I see, you are using homegrown references. For your purposes here,
> that's just fine. However, just so you know, the official XML snippets
> for RFCs, Internet-Drafts, W3C specs, etc., can be found here:
>
> http://xml.resource.org/
>
> Enjoy! ;-)
>
> On 12/14/11 12:06 PM, William Chan (陈智昌) wrote:
> > Not sure if I'm parsing your question properly, but the treeish only
> > contains the diff. If you want to see the full XML document, please
> > refer
> > to
> https://github.com/willchan/SPDY-Specification/blob/965708be7231dc60908215913f86d43454dda0ca/draft-mbelshe-spdy-00.xml.
> >
> > I'll update the document as you indicated shortly.
> >
> > On Tue, Dec 13, 2011 at 7:40 PM, Peter Saint-Andre
> <stp...@stpeter.im <mailto:stp...@stpeter.im>

[Mike Belshe]

On Tue, Nov 29, 2011 at 5:54 PM, William Chan (陈智昌) <will...@chromium.org> wrote:

On Sat, Nov 26, 2011 at 2:16 PM, Alexey Shamrin <sha...@gmail.com> wrote:

Follow-up remarks:

== Section 3.3.2, Server Push - Client implementation [1] ==

"When a client receives a SYN_STREAM from the server without an 'url'
in the Name/Value section, it must reply with a RST_STREAM with error
code HTTP_PROTOCOL_ERROR."

The sentence above contradicts section 3.3.1 (Server implementation),
which specify no headers for SYN_STREAM from the server. It only
specifies the subsequent HEADERS frame:

"The SYN_STREAM is followed by a HEADERS frame which MUST include a
header for ":scheme", ":host", ":path", which represent the URL for
the resource being pushed."

In addition I haven't found anything about HTTP 'url' header.

We used to use the 'url' header. We deprecated it due to many HTTP implementations having difficulty with fully qualified URLs. Instead, we use 'scheme', 'host', and 'path' to uniquely identify a resource. I will fix this error. And the line in 3.3.1 is misleading. It is the server SYN_STREAM which must uniquely identify the resource, by providing 'scheme', 'host', and 'path'. Then all other response headers follow in the subsequent HEADERS frame. I will try to clarify the wording here.'

This particular change hadn't made it into the draft.  I have added it.  (changing 'url' to reference ':host', ':scheme', and ':path' headers)

mike
 

[Mike Belshe]

On Wed, Dec 14, 2011 at 11:18 AM, Peter Saint-Andre <stp...@stpeter.im> wrote:

Sure. I'll send a patch if I can find the time.

On 12/14/11 12:15 PM, William Chan (陈智昌) wrote:
> I won't bother changing this yet then. I'll let Mike do the cleanup
> sweep later in bulk. Pushing to Mike's repo now instead.
>
> On Wed, Dec 14, 2011 at 11:13 AM, Peter Saint-Andre <stp...@stpeter.im

> <mailto:stp...@stpeter.im>> wrote:
>
>     Ah, I see, you are using homegrown references. For your purposes here,
>     that's just fine. However, just so you know, the official XML snippets
>     for RFCs, Internet-Drafts, W3C specs, etc., can be found here:
>
>     http://xml.resource.org/
>

I modified the xml to use the standard RFC references;   Looks like these don't display properly when you just look at the .xml file in the browser with xslt, but they do render properly when we use xml2rfc.

Mike