Re: [Zope-dev] Apache rewrite - HTTP_Host redirect issue
On 2009-9-16 01:15, Roger Ineichen wrote:
Hi Dan
I have an issue with the latest changes in
zope.publisher.http.py
The redirect method in HTTPResponse http.py line: 880
forces a ValueError. Because the Apache HTTP_HOST
and the target_host to not compare.
def redirect(self, location, status=None, trusted=False):
location = str(location)
if not trusted:
scheme, target_host, path, query, fragment = (
urlparse.urlsplit(location))
if target_host and target_host != self._request.get('HTTP_HOST'):
raise ValueError(
Untrusted redirect to host %r not allowed. % target_host)
Apache usesDOMAIN in HTTP_HOST like expected
and the method used with urlparse.urlsplit(location)
returnsDOMAIN:PORT as target_host value.
I suspect Apache does use DOMAIN:PORT if the port is a non-standard
port, ie http over anything other than port 80 or https over something
other than port 443.
Wichert.
--
Wichert Akkerman wich...@wiggy.net It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] official release policy ZTK is still not changed
Hey, Stephan Richter wrote: [snip] -1 from me too. Having the previous version avoids having to look it up in CHANGES.txt or the tags, which is really lame if you do lots of releasing. From private conversations here at the Grok sprint with Christian I think that means that the steering group has concluded the release policy remains unchanged for the ZTK. For other packages of course other approaches can be taken - the ZTK steering group takes no authority there. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] official release policy ZTK is still not changed
Hi there, Unless you think you have a great argument that you think will make significant portions of the ZTK steering group change their mind on this, this discussion should now be closed. We're sticking with our current release policy for the ZTK packages. This doesn't affect non-ZTK packages; the ZTK steering group explicitly takes no responsibility for those packages. As a personal preference of course I'd like some uniformity in this, but I can live with a divergence. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK test failures - zope.testing
On Wed, Sep 16, 2009 at 3:53 AM, Gary Poster gary.pos...@gmail.com wrote: The Ubuntu one should be easy to fix. The Windows ones may be tied up with \n \r fun. It should be trivial too, though I'll need to get a Windows VM back up--or request aid from Sidnei. ;-) I'll address these issues tomorrow. Awesome. However, there is a Windows failure that I don't think is on my plate, and I'd appreciate someone else looking at it: zope.testing-3.8.2-py2.4.egg\zope\testing\testrunner\testrunner-test-selection.txt, line 166, in testrunner-test-selection.txt . That's the very last one on http://dev.thehealthagency.com/buildbot/builders/ztk-win-py2.4%20slave-win-py2.4/builds/21/steps/test/logs/stdio . You refer to the ImportError: No module named c:.documents? I hope I fixed that one already, but didn't make a new release yet. That was the typical path with a space in it problem, as found in http://svn.zope.org/zope.testing/trunk/?rev=104110view=rev Thanks, Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Update on ztk kgs: Python 2.6 issues
Yes, I would say so. This http://zope3.pov.lt/trac/browser/zope.testing/trunk/src/zope/testing/testrunner/profiling.py#L86 Was never an official feature, also I did not see an obvious alternative http://www.python.org/doc/2.4.4/lib/profile-stats.html Apart from that, hotshot is now unmaintained and might be removed http://www.python.org/doc/2.6.2/library/hotshot.html We still have the cProfile Profiler. It seems that hotshots focus was on faster profiling, but I don't see an issue here, since nobody runs a profiler in his production environments. Best regards, Patrick On Tue, Sep 15, 2009 at 21:21, Jim Fulton j...@zope.com wrote: On Tue, Sep 15, 2009 at 12:08 PM, Patrick Gerken do3cc...@googlemail.com wrote: Hi, I have removed that profiler for python2.6 My understanding of the python api is, that we were using an undocumented feature to merge two hotshot profiler results. Since nobody maintains hotshot any longer, there probably won't be anybody adding this feature officially. Tests on 2.6 work for me now. Thanks. That's probably the right first step. Does this mean we're permanently removing this feature? That would be OK with me. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zc.zope3recipes:instance: zdaemon/eventlog rotatation
Hi, The zc.zope3recipes:instance recipe creates a zdaemon.conf which writes the transcript_log and zdaemon's eventlog to the same file. That's actually fine. ZDaemon's reopen_transcript does exactly that: it reopens *only* the transcript. So when rotating the logfile (as zc.zope3recipes does it via logrotate) ZDaemon messages still go to the old logfile. I see two obvious ways to fix that: a) Write ZDaemon's eventlog to stdout b) Add a sane way to reopen the logfile. There is a logreopen command in ZDaemon but that actually restarts the daemon process. Comments? Suggestsions? -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.zope3recipes:instance: zdaemon/eventlog rotatation
On Wed, Sep 16, 2009 at 5:28 AM, Christian Zagrodnick c...@gocept.com wrote: The zc.zope3recipes:instance recipe creates a zdaemon.conf which writes the transcript_log and zdaemon's eventlog to the same file. That's actually fine. ZDaemon's reopen_transcript does exactly that: it reopens *only* the transcript. So when rotating the logfile (as zc.zope3recipes does it via logrotate) ZDaemon messages still go to the old logfile. I see two obvious ways to fix that: a) Write ZDaemon's eventlog to stdout That won't help. The messages are coming from the controller. b) Add a sane way to reopen the logfile. There is a logreopen command in ZDaemon but that actually restarts the daemon process. Comments? Suggestsions? The controller needs to be more careful about how it manages it's log file. It needs to keep track of the handler used and, when the transacript file is reopened, it needs to remove the old handler it was using and create a new one. This is probably complicated by ZConfig which is managing the logging configuration. This is easy to deal with if you're willing to rely on the logging systems internal details. :) Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Tue Sep 15 12:00:00 2009 UTC to Wed Sep 16 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Sep 15 20:45:09 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012552.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Sep 15 20:47:09 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012553.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Tue Sep 15 20:49:09 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012554.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue Sep 15 20:51:09 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012555.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Tue Sep 15 20:53:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012556.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Tue Sep 15 20:55:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012557.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Tue Sep 15 20:57:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012558.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Tue Sep 15 20:59:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012559.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] whitespace filtering corner case in doctest
On Tue, Aug 18, 2009 at 08:53:49AM +, Reinout van Rees wrote: On 2009-08-17, Marius Gedminas mar...@gedmin.as wrote: On Mon, Aug 17, 2009 at 02:46:46PM +, Reinout van Rees wrote: In some cases, importing readline can result in the escape code ^[[?1034h= to be send (8bit on). According to the gentoo bug report (liked from your blog post), this happens if your termcap/terminfo define smm/rmm codes (meta on/meta off). ... which I didn't do, at least not consiously. Just a pretty normal OSX installation. BTW, regarding your workaround: I'd suggest using TERM=3Ddummy instead of TERM=3Dlinux, as a safer choice. Not that it should matter much in practice. That'd be better, yes. I never do anything tweaking with TERM anyway, so I don't know the options/effects. jladage suggested to do the workaround in buildout, btw: add the following to the part that generates the bin/test script: environment-vars = TERM linux This escape code isn't visible, which leads to hard to find test errors, see http://reinout.vanrees.org/weblog/2009/07/16/invisible-test-diff.html Granted, it are basically corner cases. On the other hand, it does seem to cause problems now and then, according= to my googling. Would it be ok to add it to the whitespace normalization of doctests? Opinions? Well, it's not whitespace, really... My gut feeling is that this fixup doesn't belong in the core doctest code. Ok. If this happened in my project, I'd either 1) make sure I import readline at module level, before any tests are run This doesn't work, surprisingly. It *is* a corner case. It are tests where z3c.testsetup tests that it runs tests correctly. That's a lot of tests in one sentence, which means that the test output comes from separate python processes that run tests. So if I import readline in z3c.testsetup's tests, I still get the output from the test runners that are being tested. Sigh, difficult to explain, such a recusive testing thingy :-) Sounds perfectly clear to me. I once tried to make sure zope.testing's tests covered the test coverage code, and measuring the coverage of the tests testing coverage measurement turned out to be impossible. or 2) add a renormalizer that removes the escape sequence for the test that triggers this And you'd do this per-project and not in core zope.testing, right? Fine. Uli already send me some example code, so I'll do that (and put the code snippet on my weblog so that google can find it). Perhaps it would be nice if doctest's differ escaped ASCII control characters? (You could do that too with a renormalizer.) Can we safely assume that a specific set of control characters needs to be escaped? It sounds a bit dangerous to me. ASCII and defines which characters are printable and which ones are control characters. Maybe \x9b poses a bit of a problem, since it's an escape character for some terminals, but a real character on some legacy 8bit charsets. (It's not allowed in UTF-8 sequences.) Or perhaps you mean it may make it difficult to distinguish a test printing \x1b from a test printing ^ followed by [ (assuming that's the visualisation chosen for control characters). That is an issue. BTW I've no clue why I'm replying to a month-old post. I missed it earlier somehow. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.location.pickling.PathPersistent and BBB
I asked about this before; let me do so again before assuming silence to mean consent: There's a PathPersistent class in zope.location.pickling which is decorated with a recent BBB comment, and had been questioned by a XXX comment for some time before that. The class doesn't seem to be used anywhere in Zope, so removing it would rid zope.location of some unused code. As PathPersistent is the only user of the ITraverser interface within zope.location, removing it would also make it possible to move ITraverser back to zope.traversing where it fits much better conceptionally. Does anyone object to these changes? -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.location.pickling.PathPersistent and BBB
Hello, * 2009-09-16 15:34, Thomas Lotze wrote: There's a PathPersistent class in zope.location.pickling which is decorated with a recent BBB comment, and had been questioned by a XXX comment for some time before that. [snip] Does anyone object to these changes? +1, I fully agree with the change. Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.location.pickling.PathPersistent and BBB
Thomas Lotze wrote: I asked about this before; let me do so again before assuming silence to mean consent: There's a PathPersistent class in zope.location.pickling which is decorated with a recent BBB comment, and had been questioned by a XXX comment for some time before that. The class doesn't seem to be used anywhere in Zope, so removing it would rid zope.location of some unused code. As PathPersistent is the only user of the ITraverser interface within zope.location, removing it would also make it possible to move ITraverser back to zope.traversing where it fits much better conceptionally. Does anyone object to these changes? Sounds like you did the research. I'm +1 on removing it. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
