RE: Some general SPDY feedback / questions

Yes yes... details details ;) the intent of the question and the example is
primarily to draw out information about the spdy designers original intent.
The spdy framing model opens many possibilities about what could be done
but is silent in many ways on what should. So far, to me, it seems like a
great place to start but I want to get a better sense of what issues the
authors have or may not have considered.
On Jul 18, 2012 9:01 PM, "Manger, James H" <James.H.Manger@team.telstra.com>
wrote:

> > Another example... I've been exploring the theoretical possibility of
> using spdy framing to provide an alternative to multipart/* packaging...
> imagine the following response...
> >
> > SYN_REPLY(
> >   id=1,
> >  :status=200,
> >  :version=2.0)
> > HEADERS (
> >  id=1,
> >  Content-Type: text/plain,
> >  Content-Length: 5)
> > DATA (id=1, "abcde")
> > HEADERS (
> >  id=1,
> >  Content-Integrity: 9b9af6945c95f1aa302a61acf75c9bd6,
> >  Content-Type: text/plain,
> >  Content-Length: 5)
> > DATA (id=1, "fghij")
> > HEADERS (
> >   flags: fin,
> >   Content-Integrity: d2d048a734af96bf0b7b1b24a431814a)
> >
> > Yes, this is a change to existing HTTP semantics, but this kind of
> optimization is definitely interesting... and not entirely insane.
>
>
> Doesn't this badly clash with your desire to send trailer in later
> HEADERS? When does HEADERS introduce a new part and when does it just
> provide more metadata for the current part?
>
> The PUSH mechanism might be a good alternative to multipart/* packaging.
> Make the reply a list of URIs of the parts, and push each part.
>
> --
> James Manger
>