Having thought long and hard about this, commit what I think is the new and simpler flow for version2. Pass is now handled like a miss where the object will not be cached. The main result of this is that we drag the entire object, header and body, from the backend before transmitting it to the client, thus isolating the backend from slow clients. From a software engineering point of view it is a big improvement, because it eliminates the need for all of cache_pass.c and we therefore end up with less HTTP protocol implementations. A side effect of this is that ticket #56 should be fixed now. If the object is pass'ed before vcl_fetch{} that is, in vcl_recv{}, vcl_hit{} or vcl_miss{}, no "pass this" object is inserted in the cache. The confusion between "pass", "insert" and "insert_pass" has been cleaned up, by the removal of the latter. Pipe and Pass calls vcl_pipe{} and vcl_pass{} respectively, before contacting the backend. I havn't quite decided if they should operate on the request header from the client or the one to the backend, or both. One possible use is to inject a "Connection: close" header to limit pipe to one transaction. A new vcl_hash{} has been added, it will allow customization of which fields we hash on, instead of the default "url + Host:" but this is not yet implemented. vcl_fetch{} is now called after both the headers and body have been picked up from the backend. This will allow us to do more comprehensive handling of backend errors later on. A disadvantage to this is that if the object ends up as a "pass this" object in the cache, we could possibly have released any queued requests already after the headers were received. If this is transpires as a real-world problem, we can add a vcl_fetchhdr{} which can do an early release (ie: "pass"). git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@1277 d4fa192b-c00b-0410-8231-f00ffab90ce4
Showing
Please register or sign in to comment