On 01/14/2016 05:53 AM, Amos Jeffries wrote: > This patch updates the Pipeline and ClientSocketContext class > interaction for better HTTP/2 compatibility.
FWIW, I need more time to review this. Among other things, this work might overlap with Server/ConnStateData class hierarchy problems discovered by the "Fetch missing certificates" project (Christos has posted a PREVIEW patch for that in December 2015), and I need to finish studying them. Alex. > The ClientSocketContext is renamed and shuffled to Http::StreamContext. > > The name is chosen to match the HTTP/2 "stream" terminology. Which > defines a stream as a bi-directional transaction, including request, > reply and all related 1xx informational and/or control messages. That > same word "stream" is also used in RFC7230 briefly to describe the same > "transaction" scope and details. But not formalized until RFC7540. > > Each StreamContext is assigned a 32-bit ID number from a per-connection > range of IDs on creation. HTTP/1 and FTP Server just incrementally > assign a new ID as requests are receved on a connection. HTTP/2 Server > will be assigning according to RFC7540 algorithms. > > Pipeline class is updated to use the ID number to manage its contents > rather than Pointer value matching. It is also updated to drop the > HTTP/1 specific assumptions within the Pipeline implementation. As a > behavioural requirement the sequential flow is now left for the Server > and ClientHttpRequest Jobs to ensure correctness. > > > The old "client-side" classes are now split along the following scopes: > > * ::Server / ConnStateData/ *::Server > - the AsynJob managing I/O on a client connection. > > * ClientHttpRequest > - the AsyncJob operating transaction internal behaviours and Calls. > Will make use of ConnStateData and Http::StreamContext to perform its > duties (has not yet been refactored to do so cleanly yet). > > * Http::StreamContext > - the state data for a transaction. Refcounted and used by the Server > and ClientHttpRequest Jobs for their mutual data storage. > > As noted the ClientHttpRequest part of the refactoring has not been > included in this. It still directly performs much of the tasks scoped > for Server classes and needs a restructure in how it utilizes > StreamContext members and method (or possibly whether its activity is > fully migrated to Http1::Server). That is all left for a followup patch. > > Amos > > > > _______________________________________________ > squid-dev mailing list > [email protected] > http://lists.squid-cache.org/listinfo/squid-dev > _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
