On Thu, Jul 20, 2006 at 10:10:01PM +1200, Tomek Piatek wrote: > On 20/07/2006, at 6:45 PM, Matthew Palmer wrote: > >On Thu, Jul 20, 2006 at 05:47:54PM +1200, Tomek Piatek wrote: > >>I'm playing around with the XML-RPC plugin. I swear I had it going > >>the other > >>day and now I get this error: > >> > >>xmlrpclib.ProtocolError: <ProtocolError for > >>dev:[EMAIL PROTECTED]/test/login/xmlrpc: > >>303 See Other> > >> > >>I'm running latest development version of Trac and latest > >>reviosion of > >>XML-RPC. Trac is served with "tracd". All on a Debian box. > > > >You too, huh? I've only just started playing with the XML-RPC > >plugin, and > >I've been getting 303 errors too (Ubuntu, python 2.4.1, trac as of > >last > >week). athomas hinted in my bug report (http://trac-hacks.org/ > >ticket/523, > >but closed because I agree with him that throwing 303s is probably > >more a > >Trac problem than the plugin's) that other backends may be better, > >so I'm > >going to be working on that (specifically FastCGI) tomorrow. E- > >mail me on > >the weekend to ask how it went, because I'll probably forget to > >update the > >list otherwise. > > I had a theory. I thought that it was because of how I actually get > to Trac. We're running LigHTTPd as our web server and we have a proxy > rule which sets up a proxy so that anything that goes to http:// > trac.mydomain is relayed to localhost:9090 which is where tracd is > listening.
That's not the problem, because I was accessing it directly. The 303 result was logged in the Trac serve log. > One more thing. I've just tried adding "TRAC_ADMIN" permissions to > "anonymous" and then I issued the above command again but without the > "login" bin in the URL. It works fine. So it's something to do with > the authorisation system. Yep, I noticed that too. > I've just realised something by looking at Tracd logs. The following > note could shed some light on the above problem: > > Note: Many pre-HTTP/1.1 user agents do not understand the 303 > status. When interoperability with such clients is a concern, the > 302 status code may be used instead, since most user agents react > to a 302 response as described here for 303. > > So is it Tracd that's at fault here or is it the XML-RPC plugin which > doesn't know how to deal with 303? Tracd never sends a 303 to regular logins; only a 302. Also, when it sends a 303 response, it also crashes and doesn't send the entire HTTP response. There's definitely a horrible bug in there somewhere. Tracd is actually buggy another way, too -- it sends a 303 response to a client which states it only understands HTTP/1.0, which is a protocol violation. Anyway, onto the solution: I've got one of my Trac projects running under FastCGI and it works properly (modulo a couple of irritating bugs in the XML-RPC plugin that I've put patches in the trac-hacks trac for) with authenticated XML-RPC. So it's backend specific, and there is a reasonable workaround. Since I was kinda hanging out to switch to FastCGI anyway, I'm not going to faff around too much more with why tracd is horribly broken. - Matt _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
