At 11:44 PM 7/25/2001, Christian Scholz wrote:
Apache may do this, but I did not see a clause in the HTTP spec that would require this behaviour.
Yup, I noticed that too while looking in the HTTP RFCs. I was trying to see what is "right behavior" but apparently there's no "fixed" answer. However, what about the Content-Location: header that ZServer returns? Minor issue (not sure if it even makes a difference), but shouldn't ZServer either use the Location: header if it returns "HTTP/1.0", or use Content-Location: but return "HTTP/1.1"?
For Caches it might also be good as otherwise both objects might count as two different objects.. That's why apache is doing it, I think.
That makes sense.
Zope does not do it, but sets a "base" tag.
which prevents from mirroring the site in some cases.. at least it used to be.. but that's another story.. ;-)
You hit the nail right on the head :) The reason this problem was encountered was because the webmaster of the site I'm working for uses wget to slurp the entire Zope site. We use Zope as a developmental server, from which wget creates a "mirror" loaded onto the production server. We had to put in a <BASE dummy=dummy> to prevent ZServer from putting in the <BASE HREF> tag for us, because if not wget will download the HTML files with the BASE still pointing to the dev. server. We don't want that, since we're going to publish the downloaded files on the prod. server with a different URL. I know this can be fixed after wget downloads the entire site -- use sed, perl, <insert your fave text replacement tool> etc. to parse the HTML files, but we'd rather not go that way. Right now, what we do while rendering links on the fly (DTML methods, Python etc) is to check whether the object being linked to is a folder or not. If it is, we tack on the trailing slash ourselves ;) --- John Lim