I ran into this same issue today, and not being very familiar with Scheme (I’m just trying to expose the library to Arc in a reasonable way), I wasn’t sure how to fix it. Your solution was quite helpful.

The two urls ought to refer to the same ressource. The web-server ought to return the same page for both urls.

I understand how it is supposed to work. However, in a number of websites (including yahoo and google), it doesn’t work like that which means that string->url corrupts the url.

Thanks for using PLT Scheme.

The two urls ought to refer to the same ressource. The web-server ought to return the same page for both urls.

I’ve had a look at the recommendation here:
http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2 My understanding is that semi-colons are recommended instead of ampersands but not required. This being the case, the Yahoo server is behaving reasonably. Here is a URL from google: http://www.google.co.uk/search?hl=en&q=facebook&btnG=Google+Search&meta=
Replacing ampersands with semi-colons here fails to work too
http://www.google.co.uk/search?hl=en;q=facebook;btnG=Google+Search;meta=
I can’t recall a time I have seen semi-colons rather than ampersands in a query string (admittedly I don’t look at them too closely).

Choosing to mangle valid urls by default violates the principle of least surprise and when the result doesn’t work on some fairly large real-world websites it is simply not the right thing to do.

Ian

The strange thing is that the standard recommens semi-colons instead of ampersands.
So string->url doesn’t break the url per se, it is the Yahoo server, that doesn’t follow
the standard. As you found out, you need (current-alist-separator-mode ‘amp) to force it
to use ampersands.

Strange things usually have an explanation, the PLT mailing list is the place to get it.