On Sat, Jul 14, 2001 at 08:49:34PM -0700, Chuq Von Rospach wrote:
On 7/14/01 4:32 PM, "Gerald Oskoboiny" <gerald@impressive.net> wrote:
Regarding "I think they're wrong", I respect your opinion, but the HTTP spec is the result of a decade of work on and experience with HTTP by full-time web protocol geeks...
But web geeks are not necessarily user-interface or user-experience geeks. You can perfectly correctly build a nice system that's technically correct, but not right for the users.
Sure... I agree that it's possible for a standard to be irrelevant or just not meet the needs of the users for which it was written.
But I don't think that is the case here: there really is a good reason for this distinction between get and post, and it is widely followed by popular sites *because* of the usability issues. (I would like to back up my "widely followed" claim by doing a survey of various popular sites, but don't have time today, and probably won't until Friday at the earliest :( Anyway, I am fairly confident that is the case.)
What if I have a smart system on my desktop PC that is configured to prefetch any URLs it sees in my incoming email,
Given the number of viruses, spam with URLs and other garbage out there, I'd say you're foolish (bordering on stupid), but that's beside the point.
Either that, or I value my time more than that of some stupid machine's :)
Fetching a URL into my local http cache doesn't cause a virus to be executed or anything else bad to happen, and I wouldn't use software where that kind of thing would be possible anyway.
It is an interesting issue, one I can't toss out easily; but I'm not convinced, either. I think it's something that needs to be hashed over, perhaps prototyped both ways so we can see the best way to tweak it.
Barry, what do you think about this instance? As the net moves more towards wireless, PDA, mobile-phone, stuff, could we be setting ourselves up for a later problem by ignoring this pre-cache issue Gerald's raised?
Gerald, does W3 have sample pages for "right" and "wrong" that can be looked at, or are we going to have to develop some? The more I think about this, the more I think it's case where we ought to see if we can develop a prototype that follows the standards that we like, rather than toss it out at first glance. But if we can't come up with a system that we agree is 'easy enough', then we should go to what we're currently thinking.
I included pointers to all the stuff I could think of in my first message in this thread, including a proposed implementation for mailman: http://mail.python.org/pipermail/mailman-developers/2001-January/003579.html
If you think the docs on this subject at W3C are lacking, by all means let me know.
Somewhat related, W3C recently published a note called "Common User Agent Problems" <http://www.w3.org/TR/cuap> and it was received quite well by the web community ("we need more of that kind of thing", etc.) I think there is a plan to write a similar one targeted towards site administrators, pointing out common mistakes and raising awareness about little-known but important RFC/spec details like this.
That would allow anyone in the world to sign me up for any mailman-backed mailing list, whether or not I even see the email confirmation requests. And that would be Mailman's fault, for misusing HTTP GETs.
In disagree with this -- since as you say, any number of places already misuse GET, that usage is fairly common. A user who sets themselves up for it should know (or be warned by their mail client) that it has the possibility to trigger events. I'd say it's more a client issue than a Mailman issue.
By "Mailman's fault" I meant that if mailman did this, it would be the part of the equation causing problems by not abiding by the HTTP spec. But this prefetching thing is just an example; the main point is that the protocol has this stuff built in for a reason, and there may be hundreds of other applications (current and future) that need it to be there.
And, thinking about it, since GET *can* do this, it's probably wrong for W3 to push for it not to be used that way, because if things like your pre-caching system come into common use, the dark side of the net will take advantage of it, the way early virus writers took advantage of mail clients with auto-exec of .EXE's being on by default. So aren't you setting yourself up for problems by having a technology that can, even if you deprecate it, because it sets a user expectation that's going to be broken by those wanting to take advantage of it? I've got a bad feeling about this -- your example seems to set yourself up for abuse by those looking for ways ot abuse you, and that's a bigger issue than Mailman using it -- because if all of the 'white side' programs cooperate, it just encourages creation of things (like the pre-caching) that the dark side will take adavantage of.
I'm not worried about abuse, myself; I would have set this up on my desktop system already if I had more time to hack it up...
But I'd be making this argument whether or not that were the case, since it's clearly the Right Thing to do imho...
And the more I think about it, the more it's an interesting point -- but on more than one level. Has W3c considered the implications of defining a standard that depends on voluntary acceptance here?
Which Internet standards *don't* depend on voluntary acceptance?
The HTTP spec (for example) just provides information on how HTTP is meant to work. Then people who want to do the right thing have a place to look up what the Right Thing is, and if there are ever interoperability problems between different pieces of software, people can check the spec and say "hey, look, you're doing this wrong; see rfc nnnn, sec m.m; please fix." (and if that doesn't work, there's always http://www.rfc-ignorant.org/ ;)
Because the service you propose is unsafe unless you can guarantee everyone you talk to is compliant, and we know how likely that's going to be.
I disagree that it's unsafe; I don't especially want a bunch of spam in my http cache, but don't really care about it, either.
-- Gerald Oskoboiny <gerald@impressive.net> http://impressive.net/people/gerald/