Re: Listen-Protocol Branch
William A. Rowe, Jr. wrote: At 06:26 PM 5/5/2005, Paul Querna wrote: Branch URL: https://svn.apache.org/repos/asf/httpd/httpd/branches/listen-protocol/ I have created a branch to: 1. Add a 'protocol' to the Listen Command. (done) Comments, ideas, alternatives, flames, and code review are welcome. Only a question thus far. How does http-upgrade fit in this schema? The 'Protocol' only matters for the initial protocol. If the connection later changes or upgrades, it has no effect. So, for http upgrade: # # Listen *:80 http # http is the default Listen *:80 VirtualHost *:80 SSLEngine optional /VirtualHost The configuration stays exactly the same as it currently is, since http-upgrade is just 'http' as the initial protocol. -Paul
Re: Listen-Protocol Branch
On Thu, May 05, 2005 at 04:26:41PM -0700, Paul Querna wrote: Branch URL: https://svn.apache.org/repos/asf/httpd/httpd/branches/listen-protocol/ I have created a branch to: 1. Add a 'protocol' to the Listen Command. (done) 2. Add a Protocol command to force the protocol inside a vhost. (done) It seems a little confusing to allow Listen to take a protocol argument *and* have a separate directive to do the same. Why not just use Protocol for both? Also, is this also going to fix the PR#33398 issue? Regards, joe
Re: Timeout for requests
Le 4 mai 05 à 17:34, Brian Akins a écrit : Rasmus Lerdorf wrote: Linux has SO_ACCEPTFILTER which doesn't trigger the accept until there is data, so accept filtering works on Linux too. In Linux, I have generally used setsockopt with TCP_DEFER_ACCEPT. I don't see this in the httpd 2.x source. HAVE_SO_ACCEPTFILTER is never defined on my Linux boxes (2.6). AFAIK SO_ACCEPTFILTER is defined on freebsd /Xavier
Re: [PATCH] add TCP_DEFER_ACCEPT to 2.0.54
On Wednesday 04 May 2005 22:09, Brian Akins wrote: Compiles and works in initial testing on Linux 2.6 (debian sarge). I have tried that out and found that everything is working except testing mod_perl. The reason is simple and to be expected. One test (t/protocol/pseudo_http) implements a protocol module and is expecting to get something (the string HELO) from the server before sending any data. Maybe it is worth to make this option settable via httpd.conf? Torsten pgpB8EUp3hXMX.pgp Description: PGP signature
Re: problem starting apache - __mcount runtime defn not found.
On 5/5/05, Balaji [EMAIL PROTECTED] wrote: I have built an apache dso using the make system on AIX. But when I do an apachectl startssl, it throws the following error: Cannot load /home/rbalaji/usr/local/apache2/modules/mod_dyso.so into server: rtl d: 0712-001 Symbol __mcount was referenced\n from module /home/rbalaji/usr/ Maybe that symbol will be familar to folks on the aix usenet group. ... I am using makeC++SharedLib to link and xlC_r to compile my sources. Check how apxs+libtool will compile a plain C module, and take those commands and change as little as necessary to deal with C++ (maybe just change linker and compiler to xlC_r???) and see if that helps. Set environment variable LTFLAGS to a space prior to invoking apxs so that you'll see the low-level commands which get issued.
Re: [PATCH] add TCP_DEFER_ACCEPT to 2.0.54
Torsten Foertsch wrote: Maybe it is worth to make this option settable via httpd.conf? If there is interest, I could do that. This functionality is in 2.1, so some may object to adding this feature to 2.0. I am investigating its usefulness here, however. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: svn commit: r168389 - /httpd/httpd/branches/2.0.x/STATUS
Rather than axing this comment altogether... the notes were useful. I'd like to see it back in status at least for information to those who want to fix the problem, per Justin's comments. With the right fix, I'm happy to have this fixed in 2.0 (doing nothing about the subrequest trying to glom onto the POST body.) My side of this, for future release, is focused on apreq and that comment can go away for now. Bill At 02:36 PM 5/5/2005, [EMAIL PROTECTED] wrote: Author: gregames Date: Thu May 5 12:36:32 2005 New Revision: 168389 URL: http://svn.apache.org/viewcvs?rev=168389view=rev Log: remove a vote due to lack of interest/support. this is a rare case. Modified: httpd/httpd/branches/2.0.x/STATUS Modified: httpd/httpd/branches/2.0.x/STATUS URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.0.x/STATUS?rev=168389r1=168388r2=168389view=diff == --- httpd/httpd/branches/2.0.x/STATUS (original) +++ httpd/httpd/branches/2.0.x/STATUS Thu May 5 12:36:32 2005 @@ -200,21 +200,6 @@ http://svn.apache.org/viewcvs?view=revrev=154319 +1: stoddard, striker, wrowe (as corrected in subsequent patches) -* don't propagate input headers describing a body to a GET subrequest - with no body - http://svn.apache.org/viewcvs?view=revrev=158798 - http://svn.apache.org/viewcvs?view=revrev=159410 - http://svn.apache.org/viewcvs?view=revrev=160573 - +1: gregames - -1: jerenkrantz (read_length isn't a sufficient check to see if a body - is present in the request; presence of T-E and C-L in - the headers is the correct flag.) - +/-0: wrowe (this has a negative impact on modules who wish to 'inspect' -the headers, e.g. an xml transformation affected by the query -string or request POST args. The right solution is adopt apreq, -providing an API for filters to participate in POST bodies.) - gregames: done in rev 160573 - * mod_version: New Module, Backport from trunk. Requires Minor MMN Bump. http://svn.apache.org/repos/asf/httpd/httpd/branches/mod_version_for_2.0.x +1: pquerna
RE: problem starting apache - __mcount runtime defn not found.
If you compiled your module with a -p or -pg argument, then the compiler will insert a call to mcount() at the beginning of each function. This could explain how you have an unresolved reference. It could be that the system's profile libraries were not included in the library search path. Here's what they are (taken from /etc/vac.cfg): AIX 4.3.3: -L/usr/vacpp/lib/profiled,-L/lib/profiled,-L/usr/lib/profiled AIX 5.1.0: -L/usr/vacpp/lib/profiled,-L/lib/profiled,-L/usr/lib/profiled For more specific compiling and DSO questions, you might consider posting on the comp.unix.aix newsgroup: http://groups-beta.google.com/group/comp.unix.aix?hl=enlr=ie=UTF-8 -tony -Original Message- From: Jeff Trawick [mailto:[EMAIL PROTECTED] Sent: Friday, May 06, 2005 5:17 AM To: dev@httpd.apache.org Subject: Re: problem starting apache - __mcount runtime defn not found. On 5/5/05, Balaji [EMAIL PROTECTED] wrote: I have built an apache dso using the make system on AIX. But when I do an apachectl startssl, it throws the following error: Cannot load /home/rbalaji/usr/local/apache2/modules/mod_dyso.so into server: rtl d: 0712-001 Symbol __mcount was referenced\n from module /home/rbalaji/usr/ Maybe that symbol will be familar to folks on the aix usenet group. ... I am using makeC++SharedLib to link and xlC_r to compile my sources. Check how apxs+libtool will compile a plain C module, and take those commands and change as little as necessary to deal with C++ (maybe just change linker and compiler to xlC_r???) and see if that helps. Set environment variable LTFLAGS to a space prior to invoking apxs so that you'll see the low-level commands which get issued.
Re: Listen-Protocol Branch
Joe Orton wrote: On Thu, May 05, 2005 at 04:26:41PM -0700, Paul Querna wrote: Branch URL: https://svn.apache.org/repos/asf/httpd/httpd/branches/listen-protocol/ I have created a branch to: 1. Add a 'protocol' to the Listen Command. (done) 2. Add a Protocol command to force the protocol inside a vhost. (done) It seems a little confusing to allow Listen to take a protocol argument *and* have a separate directive to do the same. Why not just use Protocol for both? The reason Listen takes the protocol argument is to apply accept filters correctly, you must map a single protocol to a single listener. Reverse mapping, ie, from lots of independent Protocol commands inside a Virtual Host to the Listener Socket seems much harder, and more confusing: Listen *:80 Listen *:9080 VirtualHost *:80 Protocol http /VirtualHost VirtualHost *:80 Protocol http /VirtualHost VirtualHost *:80 *:9080 Protocol some-other-protocol /VirtualHost Since you can have many virtual hosts that map to possibly many Listen Commands, I think this is harder to understand. (Do we use the default virtual host to select the protocol for a Listener? What if the default virtual host doesn't specify a protocol?) With the current design, the use of the Protocol command is to override the default set by the Listen Command. Also, is this also going to fix the PR#33398 issue? It could. It doesn't right now. I will look at fixing it. Thanks, -Paul
Re: Listen-Protocol Branch
Paul Querna wrote: I think mixing Listen and Protocol has the potential of confusing things more than solving problems (ala Listen and Port used to)... What is the exact problem this is trying to fix? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: Listen-Protocol Branch
Jim Jagielski wrote: Paul Querna wrote: I think mixing Listen and Protocol has the potential of confusing things more than solving problems (ala Listen and Port used to)... What is the exact problem this is trying to fix? The Problem: We do not know what protocol will be used to handle a connection until runtime. We currently cannot determine this at startup. This results in: Primary: Accept Filters and TCP_DEFFER_ACCEPT are currently not used correctly. The 'httpready' accept filter is currently applied to all sockets. This means protocols like nntp, where the server must send data first, don't work at all. Rasmus said it has the potential to cause problems with SSL Servers, but I haven't personally observed this. Secondary: Protocol modules all have a 'FooEngine' directive to activate them on a Virtual Host level. This has several problems, since for many protocols a 'Virtual Host' makes no sense. (There are lots of other issues here, with using non-HTTP protocols, but the gist is that they all require a special directive to tell if they are active for a connection.)
Re: Listen-Protocol Branch
Paul Querna wrote: The Problem: We do not know what protocol will be used to handle a connection until runtime. We currently cannot determine this at startup. This results in: Primary: Accept Filters and TCP_DEFFER_ACCEPT are currently not used correctly. The 'httpready' accept filter is currently applied to all sockets. This means protocols like nntp, where the server must send data first, don't work at all. Rasmus said it has the potential to cause problems with SSL Servers, but I haven't personally observed this. On further testing this turns out not to be the case. The machines I saw problems on were actually using a modified httpready filter that fell back to waiting for a newline instead of triggering immediately. The standard httpready filter triggers immediately when it doesn't understand the request, so it should degrade nicely for SSL requests. -Rasmus
