Re: Documentation URLs

[Michael . Schroepl]

> It is just a (imho short) question of time Google (and other search
> engines) will renew their index and rebuild the karma for the new URIs.

I am not really sure about this.

I believe the "karma" of Google is the results of popular pages linking
to certain URLs, thus assing the popularity of these pages to the rank
of the link target.
So if the link target is no longer there then it might vanish from the
Google database sooner or later (because Google traverses known sites
now and then and might recognize the redirection, thus replacing the
known URL by the new URL).
Therefore I believe changing URLs would actually make them lose their
rank in Google until other pages update their content as to link to the
new URLs, then again adding their popularity to these pages.

> Not to change the meaning of /docs will do us much more pain. I don't
> want to hear "hey, forget apache. their docs are really outdated".
> And this is, what may (will?) come some day, if we keep our current URI
> structure.

If that's the problem then I repeat my suggestion as to put a _huge_
link on the Apache 1.3 docs start page (which is where the visitors
will start if they assume the current docs to reside here) pointing
to the current version (whichever this may be) and reading "Current
Version: 2.0" or something like that.
(This link should probably be auto-generated so that updating it
 won't be forgotten in case of a change of the latest release.)

Just a question out of curiosity: Did the Apache site ever provide
documentation for versions 1.2 and 1.3 in parallel? If so, how was
the problem taken care of back then?

>> ... Another option would also be, add a checkbox for a doc cookie,
>> 'Always choose this version', which would bypass this page and
>> always redirect that browser to the right section.
>
> Uh -1.
> That would be much confusing.
>
> Vary: Cookie?
> Proxies?

I believe that "Vary: Cookie" (added via configuration for this page
alone) should solve the problem for modern proxies (Squid 2.5+).
One alternative would be to deny proxy caching for this special page
(which isn't that big after all, although it might have many hits).

Remember that sending compressed content (mod_deflate) poses the same
problem for caching proxies (which are required to understand the
negotional nature of a page sending "Vary:").
Is this the reason for not sending compressed content at all?
(Currently the Apache docs appear to be served uncompressed.)


Regards, Michael

_____________________________________________________

Diese E-Mail enth�lt vertrauliche Informationen und ist nur f�r den in der E-Mail genannten Adressaten bestimmt. Bitte verst�ndigen Sie den Absender dieser E-Mail unter folgender Rufnummer +49 (0) 69 - 717 00 0, falls Sie diese E-Mail irrt�mlich erhalten haben, und l�schen Sie diese E-Mail. Der Inhalt dieser E-Mail ist nur rechtsverbindlich, wenn er von unserer Seite schriftlich durch Brief oder Telefax best�tigt wird. Die Versendung von E-Mails an uns hat keine fristwahrende Wirkung.