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.)
> 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
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:
> 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 VanHeyningen email@example.com
If this were an official announcement from Spry-CompuServe Internet Division,
it would have begun with the phrase "FOR IMMEDIATE RELEASE."