[5255] in www-talk@info.cern.ch
Re: forms question
daemon@ATHENA.MIT.EDU (Rick Troth)
Mon Aug 22 18:38:11 1994
Date: Tue, 23 Aug 1994 00:32:14 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: troth@rice.edu
From: Rick Troth <troth@rice.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
> > hidden fields are awkward at best
> >
> > "overloaded paths" in the URL are bad
>
> Could you give some evidence? I thought hidden fields were a pretty
> good idea? What are the pitfalls? Are they real technical issues,
> or a result of *@#$#@$ broken implementations? What's wrong with
> "overloaded paths"? (what are "overloaded paths"?)
Maybe it's just emotional and nobody likes them.
My experience was more technical in that I found an unacceptable
number of clients didn't (don't) support them. I do, though,
have problems with the idea.
Look ... I'm all for giving any and all options to the
user/publisher, so I wouldn't dare suggest to do away with hidden
fields. Further, hidden fields allow the contents to flow along
the same path as the non-hidden fields regardless of the implementation.
But ... if what you want to do is pass along some (call it)
"state information" (and there are other things too, which aren't
exactly state, that fit (see my example in previous note)),
using hidden fields to do it is a hack.
> > Recommend putting state information and other optional
> >parameters after a semi-colon ";" ...
>
> I am completely lost. Why does it matter whether the ';' goes before
> or after the '?' ? Is this a CGI-BIN interface issue? A broken client
> issue? A broken server issue?
"overloaded paths" -- my term. Loose definition follows.
My understanding was that *all* (HTTP) servers parsed
what follows the "?" as "search arguments" or other data,
like form response. Presuming this is correct, then
http://serverhost/my/script;somevar=foo?othervar=fum
binds somevar=foo to the script without it being
part of the "path". So somevar=foo and othervar=fum get
get sent to different parts of anyone's server. I don't have to
code something like
pass /my/script/* /server/my/script
in the config file to pin all like-looking requests to
the same script. That's an implementation strain I don't want to
put up with. It's fine if someone has the tools to code such a feature
into their server, but it's not part of the spec and I don't think it
should be presumed to be some feature of URL syntax.
Overloaded paths are where the slash is the only delimiter
used in the "path" part (the part (if any) before the question mark
(if any)). Allow another delimiter and you don't HAVE TO have
overloaded paths. You CAN, but you're not forced into it.
I think people will usually prefer to NOT overload paths.
> Dan
--
Rick Troth <troth@rice.edu>, Rice University, Information Systems
