Found the culprit, need advise on how to fix it

[Edouard Gomez]

On Tue, 08 May 2007 22:32:47 +0000, Edouard Gomez wrote:
> Why is the stream capability advertised by the server if it's meant to
> be forbidden when the stream command is eventually sent by the client.

Well, i think i found the culprit, but i don't know how to fix it 
properly.

AFAICT, the hgwebdir object finishes spawning a hgweb object with its own 
parentui, part of the hgweb object answers stream out is supported, the 
debug output i've given proves it. That's because it uses its own 
accessors to the ui.config

When the stream_out command is eventually sent, the hgweb object calls:
streamclone.stream_out(self.repo, req)

The stream_out() function uses directly the ui object within the repo 
object, "bypassing" the usual "trust by default" behavior of hgweb. Here 
lies the inconsistency between what hgweb advertises as its capabilities, 
and what it really want to execute as commands.

I could propose to blindly trust the repo ui object as well, but iirc 
server:uncompressed was precieved as a trouble maker as it allows eating 
lot of bandwidth.

Some advise welcome for fixing this, if it's ever concidered as a problem.

PS: With the help of hgwebdir.cgi, apache server can serve lot of repos 
for lot of users w/o access to ~www-data/.hgrc file.
The idea is to allow server:uncompressed to be set on a repository base, 
ant not only as a user wide setting. So each user can control what repo 
he thinks could benefit from the uncompressed streaming.

-- 
Edouard Gomez