I don't mean to start a war. Just want to avoid future problems,
where possible.
>All I have "frozen" are the parameters, the format of output, and
>my hands this morning. I have no mention about any environment
>variables or anything else yet so I can do whatever I need with
>them.
Well, it might be that the parameter positions for NCSA httpd
may change, but your point about making changes to be compatible
is well taken.
>So would I -- so will you put the unescaping and parsing to your
>server?? :-) It's crazy to leave it for scripts since there exists
>a standard way of doing it and scripts would do this anyway. And
>no information is lost.
For simple scripts, escaping and parsing is what you want and it
does make sense. For complex scripts, you really want the server
to touch the URL as little as possible. It doesn't know what your
escaping scheme is and it shouldn't know because your script will
have to be responsible for escaping URLs in the HTML output.
Moreover, your escaping scheme may not be the "standard" one
(for http: scheme URLs, there's no requirement you use % hex escapes).
I often do escaping which keeps the URLs smaller and more human
decodable (e.g., translating ' ' -> '_').
There are two conflicting directions for an external gateway interface
to go. Either it can fully digest the request and leave the gateway
script with just the task of spitting HTML or it can keep an entirely
hands off posture and let the gateway do decoding and protocol work too.
Both are useful, but if I _had_ to choose I'd take the hand's off
version because it isn't limiting.
Escaping is fine, but an option to turn it off would be necessary.
-- George