Hi Nic,
I'm not sure why you make so much fuzz about this.
First of all, I'd like to point out that I did not make any claims about which
product does or does not support URL rewriting. I did say that URL rewriting
did not appear to be working on JSWDK, maybe because it wasn't implemented yet.
In the age of surgical strikes, your attack is quite a misser. Check your fire.
Now back to this URL rewriting issue. You seem to ignore the responsabilities
involved with a lot of the transactions going on today on the net. As browser
persistence is a crucial mechanism in the interaction and the control thereof,
reliability and security of this mechanism are of the essence. Clearly, URL
rewriting is the under-achiever here, it is by the very definition a
programmers trick, but - granted - cookies are not holy either, especially
early implementations. But the 'Cookies-are-evil' thing is really over the top,
as a lot of other conspiracy theories are. All common browsers support cookies,
and the stability and security issues are encouraging. If they come up with
something better - great. But, Nic, face it : it won't be URL rewriting.
As far as the other propostrous allegations are concerned, I do use URL
rewriting at the univ where I work (and we do have downgraded HTML versions of
pages ranging from 4.0 to 2.0, to support Lynx browsers etc.), but it's a
sandwich ordering application, Nic my boy :) Not an internet banking app :)
By the way, in the end, I find the whole discussion somewhat absurd. All this
information, both cookie and URL are always contained in the HTTP header, which
is (without encryption) always accessible. There's not much difference. But, at
least cookies don't clog up your location field and offer a standard way of
preserving information across sessions. Don't try to be a clown without having
a single funny joke - and at least your failure to understand the basic
similarities grants you just one :)
Nope that didn't help either, now did it :)) And Red Nose Day is still far away
*)
e-gret,
Danny Martens
Nic Ferrier wrote:
> >>> Danny Martens <[EMAIL PROTECTED]> 10/25/99 5:22:12
> PM >>>
>
> >I consider URL rewriting a dirty trick (see the hotmail bug),
> >with too much drawbacks to consider it any longer as a
> >serious alternative. Browser persistence has become
> >too crucial for a web-application : 99% of your target audience
> >can support cookies... no need to become a slave of the
> >overwhelming amount of (would-be) browsers out there...
>
> Come, come Danny.
>
> I don't think this is true at all - the latest versions of
> GNU-Paperclips support URL-rewriting and I can't believe the Apache
> Jserv people will not support it - Craig? Jon?
>
> Problems with cookies:
> 1. The biggest problem with Cookies is that don't like them and turn
> them off. This kills session management with them completly.
>
> 2. proxies may not implement them properly
> So this is down to a bad implementation but it still brakes things.
>
> 3. browsers may not implement them properly
> I have recently been trying to get the GNU-Paperclips session
> implementation to work satisfactorilly with cookies with both Netscape
> and IE. It doesn't, largely I think because the Netscape browsers
> don't support the cookie RFC standard but only Netscape's own (please
> correct me if I'm wrong).
>
> URL re-writing:
> It is also, frankly, nonsense to say there is something inherantly
> wrong with URL re-writing.
> It is perhaps pertinent that the example Danny cites is very unlikely
> indeed to be based on any servlet engine.
>
> I work on BTs Talk21 system where we use URL re-writing all the time
> and we have never had a poroblem with loosing sessions. Lot's of other
> problems but not that one.
>
> But the best argument is that people can turn cookies off whilst they
> can't prevent acceptance of a session encoded in a URL.
>
> I presume that Danny doesn't write servlets for these people but I'd
> rather keep them in my user profile.
>
> Nic Ferrier
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
