http://db.apache.org/derby/releases/

shows both the html and the cgi, and it isn't obvious which to click on.
Ha! I've never visited that page. Do we link to that page from somewhere on our 
website?

No, I don't think we do.

I think the reason I got there is that I had downloaded some other release, 
e.g.,

        http://db.apache.org/derby/releases/release-10.9.1.0.html

which *is* linked to from derby_downloads.html.

Then, I wanted a different release, and that page was in my browser
history, and so my browser helpfully filled in that URL, and I
decided just to back space over the stuff at the end and I was
left with the problematic URL

        http://db.apache.org/derby/releases/

So it was a combination of me trying to 'guess' a URL, together with
the fact that the valid download URLs for various releases are all
extensions of that some common base URL.

Plus, the index page that it showed me looked right; I just made the
(incorrect) assumption that since the HTML extension was correct for
release 10.9 and 10.10, it would in turn be the correct extension
for 10.11 and 10.12 as well.

I think I might not be the only person who would download

        http://db.apache.org/derby/releases/release-10.9.1.0.html
and
        http://db.apache.org/derby/releases/release-10.10.1.1.html

and then jump to the conclusion that you could just follow the
progression from '9' to '10' to '11' to '12 and try to reference

        http://db.apache.org/derby/releases/release-10.11.1.1.html
and
        http://db.apache.org/derby/releases/release-10.12.1.1.html

Which is essentially what I did.

I think we're just somewhat cursed by having such a long history
of releases, and by the unfortunate fact that the URL naming
convention changed in a fairly subtle way at release 10.11, and
it was doubly-unfortunate that the new system leaves HTML files
named according to the old convention which are NOT valid pages.

If you're OK with the proposal to put the index.html in place, that
will at least partly fix the problem, although it won't protect
people who attempt to 'predict' the URL based on our naming
convention, and thus stumble into URLs which look correct, but are
in fact wrong.

thanks,

bryan

Reply via email to