It seems hgwebdir overwrites SCRIPT_NAME wrongly.
The attached patch should fix the issue.

I'll post it to mercurial-dev with test case in a few days.

[web]
style = paper
baseurl = http://selenic.com/repo/

environment:

{'REDIRECT_UNIQUE_ID': 'SvMCDkJdEDUAAE8gqq8', 'REDIRECT_STATUS': '200', 'SERVER\
_SOFTWARE': 'Apache/1.3.34 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.\
9.8c', 'SCRIPT_NAME': '/repo/index.cgi', 'SERVER_SIGNATURE': '', 'REQUEST_METHO\
D': 'GET', 'HTTP_KEEP_ALIVE': '300', 'REDIRECT_URL': '/repo/hg/atom-log', 'SERV\
ER_PROTOCOL': 'HTTP/1.1', 'QUERY_STRING': '', 'PATH': '/bin:/usr/bin:/usr/local\
/bin', 'HTTP_ACCEPT_CHARSET': 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', 'HTTP_USER_AGEN\
T': 'Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4) Gecko/20091028 Icewe\
asel/3.5.4 (Debian-3.5.4-1)', 'HTTP_CONNECTION': 'keep-alive', 'SERVER_NAME': '\
www.selenic.com', 'REMOTE_ADDR': '10.0.0.100', 'HGRCPATH': '/home/mpm/selenic/h\
grc', 'PATH_TRANSLATED': '/home/mpm/selenic/public_html/hg/atom-log', 'SERVER_P\
ORT': '80', 'SERVER_ADDR': '66.93.16.53', 'DOCUMENT_ROOT': '/home/mpm/selenic/p\
ublic_html', 'HGENCODING': 'UTF-8', 'SCRIPT_FILENAME': '/home/mpm/selenic/publi\
c_html/repo/index.cgi', 'SERVER_ADMIN': 'webmaster@selenic.com', 'HTTP_HOST': '\
selenic.com', 'HTTP_CACHE_CONTROL': 'max-age=0', 'REQUEST_URI': '/repo/hg/atom-\
log', 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*\
;q=0.8', 'GATEWAY_INTERFACE': 'CGI/1.1', 'REMOTE_PORT': '47865', 'HTTP_ACCEPT_L\
ANGUAGE': 'en-us,en;q=0.5', 'HTTP_ACCEPT_ENCODING': 'gzip,deflate', 'UNIQUE_ID'\
: 'SvMCDkJdEDUAAE8gqq8', 'PATH_INFO': '/hg/atom-log'}

I just checked a current version (1.3.1+295-1de5ebfa5585),
it seems to be fixed when running "hg serve".

http://selenic.com/repo/hg/atom-log
and
http://selenic.com/repo/hg/rss-log
still are broken, probably running old hg version.

Isn't this happening on your repo? That's what the original reporter said,
anyway.

I don't have a test for this?

mpm, I've been looking at this, but it's a bit hard. Can you provide the
req.env contents somewhere, along with the value of web.baseurl?

To do this consistently, I'd like to start gathering some of those. I'll
think about an easier way of gathering them through some debug page...

That fix seemed hasty to me...

I think the best way to test would be to expand test-hgweb-no-path-info will
more different WSGI envs, which requires less weird setup than setting up hg
serves and should make it easy to capture all the weird cases we run into.

I was figuring that probably had something to do with my change.

There's a lot of plumbing in hgweb that the test suite doesn't touch. When I
fixed issue1679, I added a test to make sure that it wouldn't regress for
precisely this reason, but apparently I broke something that - surprise! -
didn't have a test.

I'll take a look later, time permitting.

This looks like the culprit:

changeset:   9184:f6eb03027411
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Wed Jul 22 15:26:27 2009 -0700
files:       mercurial/hgweb/hgwebdir_mod.py tests/test-hgwebdir
tests/test-hgwebdir.out
description:
Fix issue1679: path reconstruction in hgwebdir was mangling things badly

This particular area of code has a long history of back and forth
regressions. To make forward progress, we need a COMPLETE and DOCUMENTED set
of all the use cases we're trying to address, otherwise every fix for one
problem will continue to regress another.

In particular, this code probably needs to be pulled out in such a way that
we can make a unit test for it.

Upgrading to urgent as this is a regression

In mercurial-1.3.1 the links in e.g.
  http://selenic.com/repo/hg/rss-log
look like this:
  http://www.selenic.comhttp//selenic.com/repo/hg/rev/ac02b43bc08a