On Wed, Aug 08, 2001 at 01:54:53PM +0200, Raphael Quinet <quinet@xxxxxxxxxx> wrote:
> No, using a special protocol in the URI will not work, because it
then how about appendign a space and then attr=value pairs? spaces are not
valid in uris. other options incldue { } or other characters not allowed
in uris. or 8 bit characters (still not allowed in uris etc..)
> should still be possible to retrieve the file using any protocol such
> as http: or ftp: (the only difference being that you only use a part
> of it).
the question is, could it hurt us doing things like this:
<http://www.microsoft.com/favicon.ico subimage=16x16x4>
of course, there is a user interface issue: users like to enter broken
uris (usually a cut&paste issue).
> and the extra path to the image. I initially thought about this and
> then rejected the idea later because local files can have a "#" in
> their name
wenn, if we insist on uris in the api this is not a problem as # must be
escaped. but it's bad because of other reasons: # makes sense for http
uris (e.g. xpointers!) already, so we would have this:
http://...#fragment#subimage
or
http://...#subimage#fragment
both of which are "wrong".
> anything after the "#" before sending the request, and then interpret
the problem is that "#" is not nestable. and the file system layer might
want to use it itself.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
