[Vote] Add commentary system to httpd docs
I'll be a bad boy and top-post on this reply, as well as add dev@ to the list of recipients. In docs@, we have been discussing the possibility of adding comments to the various pages in our documentation. As the discussion has progressed, we have settled on the idea of trying out Disqus as a commentary system for the documentation, and I have authored a proposal on the practical implementation of this. As this is a rather large change to the documentation (if passed), Eric Covener advised me to notify both mailing lists as well as give a bit more information on how exactly this will work and why we felt it was a good idea to try out a commenting system. That information is located at http://wiki.apache.org/httpd/DocsCommentSystem We have, to give it a test spin, rolled out these proposed changed to the rewrite section of the trunk documentation, http://httpd.apache.org/docs/trunk/rewrite/ (do note that the mod_rewrite reference document is NOT a part of this test), and we'd very much like you to review these changes and let us know what you think of this solution. If everybody is happy about it, we can try to roll it out on a bit more pages, and see how it is received by the general population. So, I am calling a vote on whether or not to proceed with rolling out this test to a portion of our trunk documentation for further testing. [+/-1] Add commentary system to the trunk documentation. With regards, Daniel. On 03-05-2012 15:54, Rich Bowen wrote: I've long been a fan of the PHP documentation - specifically, the way that they solicit commentary from readers, and then fold that commentary into the docs. Not only did it encourage me to comment on the docs, it also got me involved in the PHP documentation project, at least marginally. The barrier to entry is so low that all you have to do is be a writer. As I've said elsewhere, our process seems to require that you be a programmer. I'd like to see what we can do to change that. This is why the docs@ list was split from the dev@ list in the first place. And it was at least in part why we started doing stuff in a wiki, although that hasn't been nearly as successful as I wished. I'd like to brainstorm about how we can do something like the PHP docs - provide a way for end-users to comment on a given doc, and then have a process for moderating and folding those comments into the docs themselves. The PHP docs team have offered us, on several occasions, their entire documentation infrastructure. I haven't even bothered to mention that to this list, because it would be an *enormous* change. I've discussed it in person with several docs folks, and the response has consistently been, yeah, that would be cool, but it's too big a change. But I'd be glad to have Phil write up something if people are at all interested. I digress. Does anyone know of a way to integrate a third-party comment service like, say, disqus or whatnot, into our docs, so that we could get direct feedback from our audience? Or can you think of another way that we might do this? Shosholoza. -- Rich Bowen rbo...@rcbowen.com mailto:rbo...@rcbowen.com :: @rbowen rbo...@apache.org mailto:rbo...@apache.org
Re: [Vote] Add commentary system to httpd docs
On May 4, 2012, at 9:58 AM, Daniel Gruno wrote: [+/-1] Add commentary system to the trunk documentation. Obviously, I'm +1 on this, as one of the folks who's been gently pushing for it for years. This is something that the PHP docs do right. Integrating comments into the documentation is a pretty big undertaking, but in the long run will make the docs more what our audience needs and is asking for. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [Vote] Add commentary system to httpd docs
+1 [+/-1] Add commentary system to the trunk documentation.
Re: [Vote] Add commentary system to httpd docs
[+1] Add commentary system to the trunk documentation.
Re: [Vote] Add commentary system to httpd docs
On Friday 04 May 2012, Daniel Gruno wrote: [+/-1] Add commentary system to the trunk documentation. +1
Re: [Vote] Add commentary system to httpd docs
[+1] Add commentary system to the trunk documentation. This may be worth a separate thread, but I'll just ask it here, before I forget about it: Any chance we'll see a backport of this to /current/ ? If so, will we display the same comments as in /trunk/ ? So long, i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [Vote] Add commentary system to httpd docs
On 5/4/2012 8:58 AM, Daniel Gruno wrote: [+/-1] Add commentary system to the trunk documentation. +1 -- Daniel Ruggeri
Adding unit tests to httpd?
Hi, there are some parts of httpd where unit tests would allow easier testing or more complete test coverage than tests written for the perl framework. Examples include the ap_pcfg_* functions, the varbuf API, the regex plus API, and new interfaces that are not yet used by any module. Therefore, I am thinking about adding unit tests to httpd. For maximum usefulness, such unit tests should be able to access functions that are not exported (including static functions). I could think of a few ways to achive this: 1) Add some preprocessor magic that exports the required functions when compiled with a special configure option. Then, put the unit tests into a separate module that executes them during server startup (and exits instead of allowing the startup to continue). 2) Put the unit tests into a separate executable using source files that #include the .c file(s) that contains the tested functions. This is a very hackish approach and has problems with source file interdependencies. It would likely require special linking magic. 3) Put the unit tests into the same httpd source files that contain the functions to be tested. They would only be compiled in with a special configure option. Httpd would then, if some magic -D variable is defined, execute the tests during server startup and exit instead of allowing the startup to continue. I think option 3) is the least hackish approach. Is it problematic if the unit tests are compiled into the httpd executable and modules, increasing their size? Of course, one could also compile everything twice, once for unit testing and once for production use. Newer gcc versions also have attribute cold that can put functions into a separate section, which would prevent the unit tests from using significant memory or reducing cache locality during normal operation. Any comments? Cheers, Stefan
Re: using X-Forwarded-Host as r-hostname
On 5/3/2012 5:57 PM, Chris Darroch wrote:
I promise I won't
be offended if anyone says it's a stupid hack and should never be
committed, because, well, it is arguably a very stupid hack.
Actually, I think one could make the argument that all of the headers
set by mod_proxy should be just as configurable as any other header. I
have also faced situations with reverse proxies where a little
manipulation of the headers would save a lot of hassle.
I'm +1 to the idea of making something more configurable but -1 to the
idea of proceeding with an implementation for just this one case. I've
thought on several occasions that it would be quite valuable if
mod_headers could be run on the output headers of mod_proxy, but haven't
looked into the idea.
FWIW, this recipe seems to do the trick in my test case. Definitely not
compliant since it goobers up the other X-Forwarded-* headers, but
seems to accomplish your goal. It would also be fragile if multiple
X-Forwarded-For servers are prestend... you could tweak the regex to get
past that, though... ([^,\s]+) or something like that.
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-For} (.+)
RewriteRule .* - [E=XFWD:%1]
ProxyPreserveHost On
RequestHeader set Host %{XFWD}e env=XFWD
Sample request1:
HEAD /XFwdTest/ HTTP/1.1
Host: whatever.com
X-Forwarded-Host: somethingElse.com
Connection: close
And what showed up downstream:
HEAD /XFwdTest/ HTTP/1.1
Host: somethingElse.com
X-Forwarded-Host: somethingElse.com, somethingElse.com
X-Forwarded-For: 192.168.0.2
X-Forwarded-Server: testbed.com
Connection: Keep-Alive
Sample request2:
HEAD /XFwdTest/ HTTP/1.1
Host: whatever.com
Connection: close
And what showed up downstream:
HEAD /XFwdTest/ HTTP/1.1
Host: whatever.com
X-Forwarded-For: 192.168.0.2
X-Forwarded-Host: whatever.com
X-Forwarded-Server: testbed.com
Connection: Keep-Alive
--
Daniel Ruggeri
Re: [Vote] Add commentary system to httpd docs
[+/-1] Add commentary system to the trunk documentation. +1
Re: [Vote] Add commentary system to httpd docs
On 2012 5 4 15:04, Igor Galić i.ga...@brainsware.org wrote: [+1] Add commentary system to the trunk documentation. This may be worth a separate thread, but I'll just ask it here, before I forget about it: Any chance we'll see a backport of this to /current/ ? If so, will we display the same comments as in /trunk/ ? I would assume that if the test is successful we would expand it to current and 2.2. As to whether each branch has their own comments, I think they probably should, but thats still to be decided. -- Rich Bowen rbo...@rcbowen.com
Re: [Vote] Add commentary system to httpd docs
Daniel Gruno wrote: [+/-1] Add commentary system to the trunk documentation. +1 Chris. -- GPG Key ID: 088335A9 GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
