I agree that this is the best approach if you want to implement a
service that works with everything.
>Kind of like using K&R C instead of ANSI until enough compilers get out
>there that you can justify saying "You need an ANSI compiler."
Yes. But using this analogy, I'm not proposing for you to use ANSI C,
I'm proposing to standardize it.
I'm proposing that we standardize some http feature to provide direct
support for statefull dialogs.
That you won't be able to use this standard for some time to come if
you want your statefull dialogs to work with 100% of all web users is
an entirely different matter, and cannot be used as an argument
against a standard proposal.
Only if there is no hope that the standard will not be supported by,
say, more than 90% of the software within 2 years, then you have an
argument against a standard proposal. Personally, I think that this
is a good argument against standardizing Java/SafeTcl/... support to
be present in all web browsers, like some people want to do.
[...]
>I don't see how if I pick 12 things out of a catalog before I submit the
>purchase and Jane picks a different 8, how my page can be cached and
>served to Jane.
Look a the shopping basket implementation at http://www.amazon.com .
If you have to go to a separate page to see your shopping basket
contents, the normal pages with the product (book) descriptions, look
like
+-----------------------------------------------------+
<picture of a book>
Title of book
price, isbn, etc
book description.....
[put book in my basket] [show contents of my basket]
+-----------------------------------------------------+
Thus, the looks of the page do not depend on your basket contents
(=the dialog state) at all! The html for the above page can be
cached, and sent to Albert, Jane, etc, EXCEPT for the fact that the
two buttons at the bottom of the page have links with an url-embedded
session-id. Do away with the need to embed session-ids in the html
code of the page (which is what I propose to do), and the page can be
cached.
> Now, the inline GIFs, yes, but you don't need to modify
>the URLs for them.
In response to some other people in this thread, inline GIFs are the
perfect counter-argument against a scheme in which the cache *never*
caches responses to requests that have session-id/cookie/anonymous
authentication/... headers in them.
I see nothing wrong with caches adopting the *default* of never
caching responses to requests which have session-id/... headers in
them, but there should be a way for the service provider to say `it is
OK to cache this entity (inline picture, product description page) and
serve it to people with a different session-id/...'.
[....]
> But I don't see what the session-id header
>buys you that the URL mung doesn't except that you don't have to edit
>HTML on the fly at the server.
It buys you
1) easier implementation: no editing on the fly (as you mentioned)
2) more possibilities for caching (you can cache the above product
description page). In many statefull dialogs, only a small subset
of the html entities served to the user will actually depend on
the dialog state. Example: http://www.amazon.com.
3) More possibilities for statefull dialogs. Example: a `show new
things' link leading to a `show new stuff since ... days' form
that leads to a list of links. Using session-ids/cookies/..., the
form could `remember' the number of days you filled in previously
in the session, and supply this number as a default value. This
way, the only statefull entity in this dialog is the default value
in the form. Implementing this type of statefull service for a
normal site using on url-mbedded session-ids is completely out of
the question.
4) (most importantly) It buys you *safety*.
urls-with-embedded-session-ids can cause nasty problems if stored
in hotlists, put on a `carrot lovers home page', etc.
5) urls-with-embedded-session-ids can have the bad effect of
filling proxy cache stores with useless entities. An explicit
session-id outside the url allows caches to treat statefull dialog
entities as a special case.
[....]
>Don't misunderstand. I'm not trying to derail things. I'm just trying
>to play devil's advocate so everyone involved considers the points in
>their entirety.
I have no problem with you playing devil's advocate to some extent,
but please do not proceed to the point where you start asking
questions you already know the answers to. Post the answers instead.
I know it is more work to post the answers.
> Mung'ed URLs aren't going to go away as long as 30% of
>the browsers *don't* implement expires: properly.
Actually, more than 70% of the browsers currently in use get it right.
My `70% of all popular browsers' is just another way of saying
`NetScape'.
Also, contrary to proxy caches, browsers identify themselves to the
server, so the server can mung URLs only if dealing with a broken
browser. My Futplex system
(http://gewis.win.tue.nl/applications/futplex) actually does this,
though I still need to update the broken browser recognizer to know
about the latest netscape version not being broken. Currently,
Futplex mungs URLs for NetScape and Lynx, but not for Mosaic.
BTW, Futplex provides statefull dialogs without using
url-embedded-session-ids. Instead, it uses the internet address of the
client as a session-id substitute. This has its limitations, it means
that two people behind a firewall or proxy cache cannot have a session
at the same time.
> And as far as I can
>tell, there isn't even consensus on how to implement expires: for the
>history list, so I'm not sure how you can say "expires works" for 70% of
>the browsers.
If I say `expires works in NetScape', I mean `its implementation does
not violate the current spec'. Consensus about things not in the spec
has nothing to do with it.
What I talked about in my report on problems with the expires header
(http://www.amazon.com/expires-report.html) is a much more subtle
matter than browsers "working" or "not working". BTW, I hear that
solution 2 in this report is going to be included in the next draft
http spec.
> --Darren
Koen.