Re: Ascii-based SPDY "compression" idea

  
  

------ Original Message ------
From: "Ian Fette (イアンフェッティ)" ifette@google.com
>I'm curious if under your definition of "http router" that box is 
>terminating the ssl connection and forwarding to different backends or 
>if you are speaking about the non-ssl case.
  
SSL/TLS is an orthogonal issue.  Even in SPDY we are assured it's 
optional.
  
The router is just something that forwards/routes HTTP messages, 
currently mostly a reverse proxy.
>On Apr 2, 2012 3:20 PM, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
> In message <CAA4WUYg79y39s3M=NpuUSATJQGSFJvE_PKz+rW3ZGeWbUkcQjg@mail.gmail.com>
> , =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= writes:
> 
> >It's unclear to me the point that you're making. Above, Peter said 
> "Since a
> >SPDY session is associated with a single TCP connection, we can 
> assume all
> >GETs on that connection are being routed to the same web server." to 
> which
> >you said "I think that is an unwarranted assumption."
> >
> >So, just to clarify, we're on agreement that all GETs are being 
> routed to
> >the same HTTP router, right?
> 
> Yes, they go to the same HTTP router, but very likely different
> HTTP servers.
> 
> I strongly belive that we need to recognize HTTP routers as a class
> in HTTP/2.0, a class semi-distinct from the more general proxy,
> because they handle the biggest bandwidths and look at the smallest
> parts of the HTTP headers.
> 
> Proxies with more functionality, caching or filtering for instance
> by definition needs to look at more of the metadata becuase they
> are, at some level, involved in the semantics.
> 
> But the basic HTTP-router just needs to figure out which webserver
> this goes to and the primary criteria seems to be:
>        Host:
>        URI pattern match
>        session-cookie
> in that order.
> 
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by 
> incompetence.
> 

Received on Monday, 2 April 2012 20:41:27 UTC