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