- From: M. Hedlund <hedlund@best.com>
- Date: Sun, 10 Dec 1995 14:21:56 -0700
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
At 2:13 PM 12/10/95, Koen Holtman wrote: >I believe my remark on `path=' at the time had to do with the `large >shopping bag problem'. In a tele shopping application, you could, by >using `path=', divide the shopping bag into multiple sections, each >one holding products from a different part of the shop. But a request >on the `cash register' or `I want to order and pay for the contents of >my basket' URL would have to have contain the shopping bag information >from all bag sections at once, which may lead to a Cookie request >header large enough to overrun a buffer in client, server, or proxy. > >So for shopping applications, `path=' doesn't buy you that much. You're assuming one 'checkout' operation for the whole site. At a "mall"-type site, each store could have its own directory and checkout operation. In this case, 'path' would prevent the browser from sending every cookie for the whole mall with every request. >>The disadvantage [of path] is >>that you blow away Dave's provision for an unspecified header-content. > >I don't quite see what you mean here. The NAME=VALUE pairs which >carry the actual state in the cookie headers are just as opaque as the >state information in Dave's state-info header would be. Yes, you're right. I meant only that the inclusion of path would shift away from the whole header value being opaque, to one attribute of the value being opaque. Minor point. Marc Hedlund, Organic Online <marc@organic.com>
Received on Sunday, 10 December 1995 14:23:51 UTC