Request for comments: Bug 6306820

[Richard Kennard]

Michael,

I just thought I'd tackle this point in detail...
> So, this means that an '&' embedded in a parameter could not be 
> recognised when parsing
I don't think you can have an 'embedded & in a parameter' in any 
meaningful sense. You'd have to encode it (as %26) or else it would be 
recognised as a separator by Web browsers and servers, regardless of 
whether you used semicolons for the rest of the URL. To me, the HTML 
spec doesn't imply 'if you use one separator then the other separator 
should be considered a normal character' - it just says 'ampersands and 
semicolons are separator characters'.
> through one of the add parameter methods... it would get encoded into 
> %xy. This sounds wrong to me.
I don't think it should sound wrong: the 'parse' methods parse an 
encoded String, the 'add' methods deal with unencoded Strings (and Numbers).
> it should be possible somehow to do a "roundtrip" of constructing a 
> query piece by piece, outputting
> the string, and then parsing the string again later, back into the 
> same query object.
Here we agree! And with the current version of the code, this works...

        URLEncodedQueryString queryString = URLEncodedQueryString.create();
        queryString.setParameter( "a", "x&y" );
        queryString.setParameter( "b", "u;v" );
       
        assertTrue( "a=x%26y&b=u%3Bv".equals( queryString.toString() ));
       
        queryString = URLEncodedQueryString.parse( queryString.toString() );
        assertTrue( "x&y".equals( queryString.getParameter( "a" )));
        assertTrue( "u;v".equals( queryString.getParameter( "b" )));

...is that what you were suggesting?

> All that's needed is an additional parse() method which specifies the 
> separator char.
Again, the HTML spec doesn't say 'when one character is the separator 
char then the others are normal characters', so I don't see how you can 
specify a single separator char?

If we can get this cleared up I'll post the new version of the class 
(renamed to use Url instead of URL).

Regards,

Richard.