I'm not sure I followed that, but Standards.URI does all the splitting it can do based on its understanding of the URI format /.../
It can do more splitting according to rfc 2396, namely to split paths into path segments (and path segment parameters). Not that that's something I'd want it to, since handling an array with path segment strings would be very clunky.
What are you trying to do? :-)
I'm trying to figure out on which level a problem with insufficient decoding should be fixed. I think I know now.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-05-26 17:20: Subject: Quoting in Standards.URI
Seems like Standards.URI do neither encoding nor decoding according to rfc 2396:
True; it is kind of dumb that way; it just gives you the tools to take an URI apart and put it together again. We never got as far as setting an API for how to handle quoting, encoding and decoding issues for a higher level API; it was left out for possible future improvement.
I think it's pretty clear that it should handle this detail too.
Agreed. I do not think there would be any problem with compatibility, though, adding something now to do the trick, but then I also do not think encoding and decoding should happen automagically. Adding some additional primitives to the class should pose little problems, IMO.
Hmm, I just realized that it strictly speaking isn't possible to decode the path without splitting it at the same time. Is this true for the other uri parts too?
I'm not sure I followed that, but Standards.URI does all the splitting it can do based on its understanding of the URI format and all parts you get from it can then be decoded using tools elsewhere. The query part, for instance, can not contain an unquoted # character, nor can (assuming HTTP GET variable semantics) HTTP URL variable names contain an unquoted = character (which I believe might answer your question).
What are you trying to do? :-)
/ Johan Sundström (Achtung Liebe!)