I'd also like to see something more general. (I'd also like to see something
integrated with, rather than orthogonal to, existing fragment references
but that's just me.)
> http://host/path/to/object?object_arguments;request_headers
>
> object_arguments: a url-encoded list of name-value pairs
> i.e. name=brian&age=22
>
> request_headers: a url-encoded list of request headers, which only
> make sense in the context of the protocol used (in this case HTTP)
> This generality is so that URL's aren't hindered by HTTP-only
> specifications.
This also has interesting potential to allow hacks like the extra anchor
stuff like DN and CRYPTOPTS in SHTTP to be folded into the URLs.
> I can already sense some problems. Here's an interesting URL:
>
> http://whitehouse.gov:25/;MAIL+FROM=madmad@bomber.org&RCPT+TOpresident&DATA\nFrontLawn,2pm,May16th\n.\n
>
> Though I suppose some catches could be put in place for this situation,
> can we protect against that for every protocol? At what point does a
> sufficiently obfuscated (to the human eye) extended URL become a malicious
> virus-ish mechanism for mayhem?
You can do that today with Gopher URLs; this vulnerability has been known
about for years, popular browsers are susecptible to it, and nobody seems to
be complaining, so obviously it's not a real problem. :-) * 0.5
- Marc
Marc VanHeyningen marcvh@spry.com
Disclaimer:
If this were an official announcement from Spry-CompuServe Internet Division,
it would have begun with the phrase "FOR IMMEDIATE RELEASE."