Graham Dumpleton
graham.dumpleton at gmail.com
Tue May 29 22:52:31 EDT 2007
Ignore that, print prev, next, main should just yield object id information. Will not try and print out anything meaningful. Your internal redirect must be looping on itself somehow. If this is your fixup handler, at the start of it add: if req.prev is not None: return apache.OK if req.,ain is not None: return apache.OK This will stop it doing anything in a subrequest. Graham On 30/05/07, Graham Dumpleton <graham.dumpleton at gmail.com> wrote: > Don't print values of req.prev, req.next or req.main as when they are > in turn printed they may follow back through the opposite link and > cause a loop. If you really want to print something, print: > > req.prev is None > > ie., boolean value of whether it is None or not. > > On 30/05/07, Aaron Gallagher <habnabit at gmail.com> wrote: > > req.log_error('Redirect 3, "%s"' % req.uri, apache.APLOG_DEBUG) > > req.internal_redirect('%s?_404&orig=%s' % (ROOT, escape(os.path.join > > (req.fulluri, page)))) > > req.log_error('Redirect 3, "%s" "%s" "%s"' % (req.prev, req.next, > > req.main), apache.APLOG_ERR) > > req.log_error('Redirect 3 done (%s)' % req.fulluri, > > apache.APLOG_DEBUG) > > return apache.DONE > > > > That causes the page to be printed over and over and "Redirect 3" to > > also be printed over and over in the log. The same thing happens if I > > do if req.prev etc. before I print them. > > > > On May 29, 2007, at 7:31 PM, Graham Dumpleton wrote: > > > > > Sorry, that doesn't make any sense at all. Are you able to post the > > > code you are using? This is getting all too hard to follow when one > > > can only make assumptions about what you are doing. > > > > > > Graham > > > > > > On 30/05/07, Aaron Gallagher <habnabit at gmail.com> wrote: > > >> On May 29, 2007, at 4:23 PM, Graham Dumpleton wrote: > > >> > > >> > On 30/05/07, Aaron Gallagher <habnabit at gmail.com> wrote: > > >> >> Also, I seem to actually be having bizarre problems with my > > >> >> redirects. When I request /a/b/c/d/, my handler catches the bad > > >> URL > > >> >> and executes this code: > > >> >> req.internal_redirect('/?__404') > > >> >> return apache.DONE > > >> >> > > >> >> What happens is I get a page that has a text/plain mime type > > >> with a > > >> >> 200 response code that looks essentially like this (stripping > > >> out a > > >> >> lot of HTML): > > >> >> Page not found: /d/ > > >> >> Page not found: /c/d/ > > >> >> Page not found: /b/c/d/ > > >> >> Page not found: /a/b/c/d/ > > >> >> > > >> >> I found that after the redirect, the handler (which is a > > >> >> fixuphandler) doesn't recur, but return apache.DONE, and then > > >> another > > >> >> handler is called. My only thought could be that this is > > >> intrinsic to > > >> >> the fixuphandler, but that seems silly. Skipping the redirect and > > >> >> just returning 404 seems to work, and it doesn't return four not > > >> >> found pages. > > >> >> > > >> >> What do I need to do to fix this? > > >> > > > >> > This is probably the problem with autoindex I briefly mentioned. > > >> To do > > >> > an index it actually does a sub request as far as the fixup handler > > >> > phase for every item which it might list in the index to > > >> determine if > > >> > it has access rights and should be listing it. If you have handlers > > >> > for these phases it will trigger them for the subrequest as well > > >> which > > >> > might cause issues. One can detect if such a handler is called in > > >> > subrequest by looking whether req.prev or req.main (cant remember > > >> > which), is not None. > > >> > > >> I just tried this, and whenever I tried to access req.prev or > > >> req.main (even req.next), the request would be scrapped and a new one > > >> created, that would get to the same point before starting again. I > > >> would have thousands of lines of "Debug: preparing to redirect" > > >> before I would just have to cancel the page from loading. > > >> > > >> > When I get a chance to at least get directory index to week as you > > >> > indicate what you want, then we can start stepping through these > > >> > others issues. > > >> > > > >> > Graham > > >> > > >> Aaron Gallagher > > >> <habnabit at gmail.com> > > >> > > >> > > >> > > > > Aaron Gallagher > > <habnabit at gmail.com> > > > > > > >
|