A plugin can not extend HTTP headers of the main trac site if it is a private trac.

[martin@…]

I'm trying to make yahoo.com OpenID provider not complain about "fraudulent" sites by implementing OpenID 2.0 XRDS discovery to the ​th:AuthOpenIdPlugin copy @ ​http://ideelabor.ee/opensource/log/python-components/authopenidplugin

Discovery requires the 'base URL' of the trac instance (example.com/trac/project1) to have a X-XRDS-Location header pointing to a XML file. I got over the problem of 'tapping' into wiki module by calling irectly the process_request method of WikiModule after I've added the extra header in the tapping request match: ​http://ideelabor.ee/opensource/changeset/154/python-components/authopenidplugin

A quick test with a public wiki (anonymous has WIKI_VIEW rights) and yahoo.com had success, but trying another project where anonymous users have zero rights, the wiki system raises a permissions error with req.send_error which clears all outgoing headers set before via this hack.

Question: How can I make a plugin emit an extra header on the main page of the trac instance?

Maybe req.send_error should not clear experimental (X-*) headers?

[Remy Blank]

To avoid having to "tap" the process_request() method of the wiki module, you could implement the IRequestFilter interface in your plugin, and add headers in post_process_request().

send_error() indeed clears all previously set headers. OTOH, your site should not be displaying an error page at the root, should it? You could use fine-grained permissions as described in TracFineGrainedPermissions to give anonymous WIKI_VIEW permission on the front page only.

[osimons]

post_process_request() has the added advantage of being called when preparing errors as well, so if you add your header there (req._outheaders.append(('XStuff', 'x-stuff-value'))) it should be part of all Trac responses.

[Remy Blank]

Unfortunately not. Request.send_error() clears self._outheaders before setting its own headers and sending the response. It is called in _dispatch_request(), after calling the various request handlers and hooks in RequestDispatcher.dispatch().

[martin@…]

Giving permissions is not the goal to achieve - the trac instance is supposed to be private, even the front page.

[Remy Blank]

Replying to martin@…:

Giving permissions is not the goal to achieve - the trac instance is supposed to be private, even the front page.

I was trying to provide an alternative way to solve the issue. If this is not possible for you, then your only option currently is to patch Request.send_error(), either directly in the Trac sources or by monkey-patching it from an IRequestFilter.

I am not sure if adding arbitrary headers to an error page is a good idea, but if you can come up with a clean patch that opens this functionality to plugins, it could be considered.

And no, not clearing X-* headers is not a clean way of implementing this, IMO.

[martin@…]

And no, not clearing X-* headers is not a clean way of implementing this, IMO.

What is the point of clearing all headers in the first place ?

[Remy Blank]

Replying to martin@…:

What is the point of clearing all headers in the first place ?

I don't know. I was hoping that one of the other developers would chime in. As errors are generated during a request, where headers might have been set for the page initially to be displayed, I suppose it is intended to avoid leaving cruft from an unfinished request in the headers.

[Christian Boos]

Milestone 1.0 deleted