Robin H. Johnson wrote: > - Using the ';' as an argument separator in the old side is not a valid > query argument separator, and there are URLs out there that have added > further arguments using it, complicating parsing.
What is source of your definition of "valid query argument separator"? > - See also RFC1738: 'Within the <path> and <searchpart> components, "/", > ";", "?" are reserved.' My copy of RFC1738 says (end of section 2.2): Many URL schemes reserve certain characters for a special meaning: their appearance in the scheme-specific part of the URL has a designated semantics. If the character corresponding to an octet is reserved in a scheme, the octet must be encoded. The characters ";", "/", "?", ":", "@", "=" and "&" are the characters which may be reserved for special meaning within a scheme. No other characters may be reserved within a scheme. I wasn't able to find your quote in that file. > - Having a single valid URL for a given resource greatly improves cache > hit rates (and we do use caching heavily on the new site, 60% hit rate > at the moment, see further down as well). Redirecting clients to new URLs would give you perfect caching as well. > - The old parsing and variable usage code was the source of multiple > bugs as well as the security issue that shuttered the site. Only because it passed the raw, unescaped values directly to shell, which is of course badly broken. > - I _want_ old sites to change to using the new form, which I do > advertise as being permanent resource URLs (as well as being much > easier to construct, take any "[CAT/]PN[-PF]" and slap it onto the > base URL, and you are done). Which isn't a reason for breaking old links, IMHO. > That said, if somebody wants to point me to something decent so that > Squid can rewrite the URLs WITH the query parameters (the built-in squid > stuff seems to ignore them) and hit the cache, and that can add a big > warning at the top of the page, I'd be happy to use it for a transition > period, just like the RSS URLs (which are redirected until January 2008, > but only because they are automated, and not browsed by humans). Now that's something that sound reasonable. Why limit the period and don't provide it forever? Don't get me wrong, I really appreciate your (and others') efforts on getting p.g.o back up again, but I don't agree at all with reasons given in this mail. If you said "because I didn't have time to do that" or "I'm not interested in that", I wouldn't argue (but might try to get in touch with you and provide patches fixing the stuff). Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth
signature.asc
Description: OpenPGP digital signature
