- From: Simon Spero <ses@tipper.oit.unc.edu>
- Date: Wed, 18 Oct 1995 10:21:58 -0700 (PDT)
- To: Shel Kaphan <sjk@amazon.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed, 18 Oct 1995, Shel Kaphan wrote: > > > > The question that occurs to me is whether this is worth the additional > complexity in terms of bandwidth savings. I can't see any reason > other than bandwidth savings in the chain of requests that such a > construct would be wanted. (Is there one?). If this is right, then it > seems unlikely to produce enough savings to be worth the trouble. > This seems especially true if proxies are going to be multiplexing > requests from multiple clients onto a single connection to an > "upstream" server. It's certainly possible to make this work, but does it > buy enough to be worth the trouble? > I'll describe the HTTP-NG approach to the issue of header caching as used in 1.0->NG->1.0 relay mode. Each request takes place in a Context; a context is a bunch of state associated with a set of requests. When a client proxy relays a 1.0 request, it can set a boolean indicating whether headers should be reused or not. If headers are reused, then any request headers sent with this request are merged with those used for the previous request; if a header is not sent, then its value is reused as is; if they are sent then the value is replaced. A typical client might use two contexts; one for base pages, another for renderable inlines. The savings can be quite useful, especially if some sort of application nagle like algorithm is used to merge short requests into a single packet; an entire pages worth of cache checks can fit into a single packet. The effect becomes even more pronounced when native NG requests are used. Simon ---- (defun modexpt (x y n) "computes (x^y) mod n" (cond ((= y 0) 1) ((= y 1) (mod x n)) ((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n)) (t (mod (* x (modexpt x (1- y) n)) n))))
Received on Wednesday, 18 October 1995 10:23:36 UTC