Re: cvs commit: httpd-2.0/modules/http http_protocol.c
On Wed, May 29, 2002 at 06:42:59AM -, [EMAIL PROTECTED] wrote: ctx-remaining = get_chunk_size(line); There remains a type mismatch in this code (ctx-remaining is an apr_off_t while get_chunk_size() returns a long). Will this cause any problems? I'm thinking get_chunk_size can just return an apr_off_t, but I'm too sleepy to think about this right now. :) -aaron
mod_info flaw
In the output of mod_info, sometimes a container header (like: Limit ...) is duplicated. Here's a snippet from the output of the current www.apache.org server, and at line 26, an extra Limit header was added (dup of 24). (At the end, I attach the relevant part from httpd.conf) (Sorry about line 6: Mozilla does not break lines copied from mod_info's output :-( ) 1 Module Name: mod_access.c 2 Content handlers: none 3 Configuration Phase Participation: Create Directory Config 4 Request Phase Participation: Check Access 5 Module Directives: 6 order - 'allow,deny', 'deny,allow', or 'mutual-failure'allow - 'from' followed by hostnames or IP-address wildcardsdeny - 'from' followed by hostnames or IP-address wildcardsCurrent Configuration: 7 Files ~ ^\.ht 8 Order allow,deny 9 Deny from all 10 /Files 11 Directory /usr/local/apache/icons 12 Order allow,deny 13 Allow from all 14 /Directory 15 Location /cgi-bin/phf* 16 Deny from all 17 /Location 18 Directory / 19 deny from env=badrobot 20 /Directory 21 Directory /www 22 deny from env=badrobot 23 /Directory 24 Limit GET POST OPTIONS PROPFIND 25 Order allow,deny 26 Limit GET POST OPTIONS PROPFIND 27 Allow from all 28 /Limit 29 Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK 30 Order deny,allow 31 Deny from all 32 /Limit --snip-- Directory /home/*/public_html AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch Includes ExecCGI Limit GET POST OPTIONS PROPFIND Order allow,deny Allow from all /Limit Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK Order deny,allow Deny from all /Limit /Directory --snip-- -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: v1.3.25 (PR#9181)
On Tue, May 28, 2002 at 09:56:38AM -0700, Sander van Zoest wrote: Can we add in PR#9181? More and more people will run into this issue. -0.5 (it's a feature, and is actively being used by many). Or did you mean add the new directive AcceptPathInfo off? In that case, +1 (but within the time frame, not required for a 1.3.25 release IMO). Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: v1.3.25 (PR#9181)
On Wed, 29 May 2002, Martin Kraemer wrote: On Tue, May 28, 2002 at 09:56:38AM -0700, Sander van Zoest wrote: Can we add in PR#9181? More and more people will run into this issue. -0.5 (it's a feature, and is actively being used by many). Or did you mean add the new directive AcceptPathInfo off? In that case, +1 (but within the time frame, not required for a 1.3.25 release IMO). Ehmm.. I meant the one in the Bugzilla database. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9181 Cheers, -- Sander van Zoest [EMAIL PROTECTED] San Diego, CA, US http://Sander.vanZoest.com/
Re: [suggestion] ShebangAlias directive - to keep to make CGI scripts more portable
I'm glad you like the idea. I hope it will be implemented as soon as possible. Best regards, Webmaster33 *** REPLY SEPARATOR *** On 2002.05.28 at 09:27 Bill Stoddard wrote: I am +1 in concept on this. If I don't hear any strenuous objections, I'll update the STATUS file with the suggestion. Bill Yep, I know about the ScriptInterpreterSource directive. You may know, there are many problems for newbie users, who usually don't know how to solve to have their Perl scripts being portable, executabe also on Unix Windows boxes, without the need of altering the shebang line. The suggested ShebangAlias directive, would mean an easy-to-understand solution for newbie users. Also webmasters support persons would be glad, because they would be able to easily point to this directive instead to explain, how to use the ScriptInterpreterSource directive registering the correspondent appropiate extensions. I hope developers will like the idea, and if there is no such development under way, will implement the suggested feature into one of future Apache 2.x versions. Thanks, Webmaster33 *** REPLY SEPARATOR *** On 2002.05.27 at 08:46 Bill Stoddard wrote: Checkout the ScriptInterpreterSource directive. It is not quite as flexible as your suggestion but it may solve the problem. Bill - Original Message - From: Webmaster33 [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 27, 2002 8:03 AM Subject: [suggestion] ShebangAlias directive - to keep to make CGI scripts more portable Hi All, As I know there is a planned config feature to be able to override the shebang line, but as I know there is no any result for it, yet: -- * PR#4241: config Need to be able to override shebang line to make CGI scripts more portable. Status: AND 4241 config suspended Need to be able to override shebang line to make CGI scripts \ more portable. -- I would suggest a ShebangAlias directive for the Apache config file. I don't know if there is already something similar under development, but this feature would be very important for those users who would like to use their Perl scripts with the least possible modification when they are porting their scripts, or are just developing under Windows environment, later are running their scripts on Unix server. This would really help us to make CGI scripts more portable. Would look like following: ShebangAlias /usr/local/bin/perl C:/Perl/bin/perl.exe Any info about similar feature, which may be under development would be fine... Thank you, Webmaster33 *** END REPLIED MESSAGE *** *** END REPLIED MESSAGE ***
Client socket
Hi, Where is the client socket fd stored in the request_rec structure? Is it either of the r-connection-client-fd or the r-connection-client-fd_in variables? I tried accessing the values, but both the variables show the value '3' for every request passed to the php module. Tx, Vinod. --- Vinod Panicker [EMAIL PROTECTED] Sr. Software Designer Geodesic Information Systems Ltd.
Re: Client socket
Vinod Panicker [EMAIL PROTECTED] writes: Hi, Where is the client socket fd stored in the request_rec structure? Is it either of the r-connection-client-fd or the r-connection-client-fd_in variables? I tried accessing the values, but both the variables show the value '3' for every request passed to the php module. Why is 3 incorrect? Did you do lsof on your httpd process while stopped in the debugger to verify that 3 is (or is not) the connection to the client? Why do you need access to the socket? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: Client socket
Hi Jeff,
Thanks for your reply...
Let me explain what exactly I did.
I made changes to the php_apache.c file and added a new php function of
my own, which is supposed to return the client socket when called from a
php script. Here is the code for the function -
---
/* {{{ proto int apache_client_socket()
Get the client socket */
PHP_FUNCTION(apache_client_socket)
{
RETURN_LONG(((request_rec
*)SG(server_context))-connection-client-fd);
}
---
I recompiled php and made a module out of it. Worked perfectly. Now, I
wrote a php script with the following code -
---
?
echo apache_client_socket();
?
---
This script I call from the browser, and everytime it displays a '3'. I
even called it from different browser windows, still the same.
That cant be alright since if the fd is 3 as shown in one browser
window, it has to be something different in the other window since the
browser defaults to a keep-alive connection, and the fd's have to be
different.
I'll would tell you why I need the socket, but I've described it so many
times that I'm gonna die :( I'll forward you a mail if you are really
interested.
Tx,
Vinod.
---
Vinod Panicker [EMAIL PROTECTED]
Sr. Software Designer
Geodesic Information Systems Ltd.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Trawick
Sent: Wednesday, May 29, 2002 4:19 PM
To: [EMAIL PROTECTED]
Subject: Re: Client socket
Vinod Panicker [EMAIL PROTECTED] writes:
Hi,
Where is the client socket fd stored in the request_rec structure?
Is it either of the r-connection-client-fd or the
r-connection-client-fd_in variables?
I tried accessing the values, but both the variables show the value
'3' for every request passed to the php module.
Why is 3 incorrect? Did you do lsof on your httpd process while stopped
in the debugger to verify that 3 is (or is not) the connection to the
client?
Why do you need access to the socket?
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
Re: v1.3.25 (PR#9181)
On Wed, May 29, 2002 at 12:53:20AM -0700, Sander van Zoest wrote: On Wed, 29 May 2002, Martin Kraemer wrote: On Tue, May 28, 2002 at 09:56:38AM -0700, Sander van Zoest wrote: Can we add in PR#9181? More and more people will run into this issue. -0.5 (it's a feature, and is actively being used by many). Or did you mean add the new directive AcceptPathInfo off? In that case, +1 (but within the time frame, not required for a 1.3.25 release IMO). Ehmm.. I meant the one in the Bugzilla database. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9181 Yep. +1 on that one. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
[PATCH] fix mod_deflate uninitialized var
I assume this is a real problem?
mod_deflate.c: In function `deflate_in_filter':
mod_deflate.c:533: warning: `zRC' might be used uninitialized in this function
Index: modules/filters/mod_deflate.c
===
RCS file: /home/cvs/httpd-2.0/modules/filters/mod_deflate.c,v
retrieving revision 1.10
diff -u -r1.10 mod_deflate.c
--- modules/filters/mod_deflate.c 29 May 2002 10:27:05 - 1.10
+++ modules/filters/mod_deflate.c 29 May 2002 13:38:57 -
@@ -669,6 +669,10 @@
ctx-stream.next_in = (unsigned char *)data;
ctx-stream.avail_in = len;
+/* make sure we don't get a false match on Z_STREAM_END
+ * if we skip the loop
+ */
+zRC = Z_STREAM_END + 1;
while (ctx-stream.avail_in != 0) {
if (ctx-stream.avail_out == 0) {
apr_bucket *tmp_heap;
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
Re: don't try this at home
On Wed, May 29, 2002 at 02:47:35PM +0200, Martin Kraemer wrote: But IMO we need to have a way to parse the hex string and detect an integer overflow at the same time. If an overflow occurs, then an 4XX message is appropriate (400 Bad Request rather than 413 Request Entity Too Large) I mostly agree on the codes (not that it matters that much if it's 400 or 413, but I'm sure Roy has an opinion on this). I would think that 400 makes sense for overflow, but then again, if we can't handle the size it's not really a bad request... Then, as a second step (if the number parsed all right, even if it was incredibly long, as in this chunk of 33 bytes: 00021 CRLF ) we can try and verify whether we accept the size. For that, we have an upper limit defined by LimitRequestBody bytes. Anything beyond that can impossibly be accepted. With this I completely agree with, but I think this is already happening. I'd need to review the code to be sure. Thanks for the leading-zeros hint, I'll fix that momentarily. -aaron
Re: cvs commit: httpd-2.0 STATUS
Sander Striker wrote: Correct me if I'm wrong, but I didn't see Brian say he is against. His benchmarks show that the patch doesn't affect httpd performance, so I don't really get where this is comming from. Can someone point me to a message ID? Furthermore, you left Ian out of the loop, who was +1 IIRC. Start running dadelus with it. It works well or it doesn't. And roll it into 2.0.37 if it does. Good point. But I'll have to lean on Greg Ames for that... I don't have sudo on daedalus. I will put it up on icarus though. Why not just bump the tag? Brian already pounded it using a config/test case designed to stress it. It survived, doesn't degrade performance, and no one who is using HEAD from the last 3 days has complained. Greg
[PATCH] TPF InetD change to src/os/tpf/os.c
This patch reworks some of the checks in TPF's os_check_server function
to better accommodate TPF's Internet Daemon processing.
David McCreedy
Index: apache-1.3/src/os/tpf/os.c
===
RCS file: /home/cvs/apache-1.3/src/os/tpf/os.c,v
retrieving revision 1.17
diff -u -d -b -r1.17 os.c
--- apache-1.3/src/os/tpf/os.c 19 May 2002 04:55:39 - 1.17
+++ apache-1.3/src/os/tpf/os.c 29 May 2002 14:59:53 -
-448,25 +448,25
int os_check_server(char *server) {
int *current_acn;
-if (zinet_model == INETD_IDCF_MODEL_NOLISTEN) {
-/* if NOLISTEN model, check with ZINET for status */
-if (inetd_getServerStatus(server) == INETD_SERVER_STATUS_INACTIVE) {
-return 1;
-}
-/* and check that program activation number hasn't changed */
+/* check that the program activation number hasn't changed */
current_acn = (int *)cinfc_fast(CINFC_CMMACNUM);
if (ecbp2()-ce2acn != *current_acn) {
-return 1;
+return 1; /* shutdown */
}
-} else {
-/* if DAEMON model, just make sure parent is still around */
+/* check our InetD status */
+if (inetd_getServerStatus(server) != INETD_SERVER_STATUS_ACTIVE) {
+return 1; /* shutdown */
+}
+
+/* if DAEMON model, make sure parent is still around */
+if (zinet_model == INETD_IDCF_MODEL_DAEMON) {
if (getppid() == 1) {
-return 1;
+return 1; /* shutdown */
}
}
-return 0;
+return 0; /* keep on running... */
}
void os_note_additional_cleanups(pool *p, int sd) {
Re: cvs commit: httpd-2.0 STATUS
On Wed, 29 May 2002, Greg Ames wrote: Why not just bump the tag? Brian already pounded it using a config/test case designed to stress it. It survived, doesn't degrade performance, and no one who is using HEAD from the last 3 days has complained. I will include this in JCW_PRE2_2037, which I plan on tagging later today. --Cliff
Re: Client socket
On Wed, May 29, 2002 at 04:27:59PM +0530, Vinod Panicker wrote: This script I call from the browser, and everytime it displays a '3'. I even called it from different browser windows, still the same. That cant be alright since if the fd is 3 as shown in one browser window, it has to be something different in the other window since the browser defaults to a keep-alive connection, and the fd's have to be different. Each connection is handled in a different process and each process's fd 3 is different. If a process fork()s two children and each child accept()s a connection they will each receive a different connection but it will be allocated the same fd number in each child. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ CROMARTY: SOUTHEASTERLY VEERING SOUTHWESTERLY 5 OR 6, DECREASING 4. RAIN THEN SHOWERS. MODERATE BECOMING GOOD.
RE: [PATCH]: 64-bit porting issue in apr_sdbm.h
Please review and commit the following patch. Thanks, Mohan -Original Message- From: GUMMALAM,MOHAN (HP-Cupertino,ex2) [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 3:26 PM To: '[EMAIL PROTECTED]' Subject: [PATCH]: 64-bit porting issue in apr_sdbm.h There is a 64-bit issue with the apr_dbm.h sources -- this results in a WeDAV failure on a 64-bit OS. The problem is in the CONVERT_DATUM macro, which coverts a apr_datum_t* to apr_sdbm_datum_t*, through casting. I am sending a patch for fixing the apr_sdbm_datum_t structure. Can somebody evaluate this and commit it? Thanks, Mohan Index: apr_sdbm.h === RCS file: /home/cvspublic/apr-util/include/apr_sdbm.h,v retrieving revision 1.10 diff -u -r1.10 apr_sdbm.h --- apr_sdbm.h 13 Mar 2002 20:40:48 - 1.10 +++ apr_sdbm.h 5 Apr 2002 23:10:28 - @@ -88,7 +88,7 @@ /** pointer to the data stored/retrieved */ char *dptr; /** size of data */ -int dsize; +apr_size_t dsize; } apr_sdbm_datum_t; /* The extensions used for the database files */
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
Thomas Eibner wrote: Anyone looked at the remaining open bugs in 1.3 and might want to include this patch (and bug)? Only if someone can verify that this patch actually does anything. The proxy has been largely rewritten since then, so this bug might not still be outstanding. There is a release coming out in another day or two, I am stuck offline - can someone take a look at this fix and see if it works...? Would it also be possible to have mod_proxy for 1.3 set the same X-Forwarded-* headers as the 2.0 proxy does? Need patches for this? I thought v1.3.24 already did this - don't remember if I added it to v1.3 as well, I am sure I did. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: [apache-modules] Setting bytes_sent in Request Record while generatingall headers by myself in Apache 1.3
Just FYI.. another datum on the 'AG are snobs' scale.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! ---BeginMessage--- Thomas Eibner wrote: On Tue, May 28, 2002 at 01:21:59PM +0200, Anthony Howe wrote: Are you using Apache 1.3? Are you using mod_proxy? I submitted a long time ago a patch to Apache to fix a bug in mod_proxy, which fails to update the bytes_sent field. Don't know if they ever included it, but I have it still if required. Why not check up on wheter it actually was included/fixed and then submit a patch if it is still broken? Otherwise it will never make it into the 1.3 branch (which btw is having it's last release very soon now.) Well from what I can tell from just looking at 1.3.24, they STILL haven't included the patch. I'm sure I already submitted the patch sometime ago, 14 Nov 2000, old bug database number 6841, and its STILL open. I figure if they can't address a one line patch when it was submitted then, why should I keep pushing for something only to be ignored. Obviously someone doesn't think my input is worth anything or that my patch breaks something else. I figured I was doing my part by submitting the bug in the first place. Oh hum. -8-- Full text of PR number 6841: Received: (qmail 3213 invoked by uid 501); 14 Nov 2000 14:17:09 - Message-Id: [EMAIL PROTECTED] Date: 14 Nov 2000 14:17:09 - From: Anthony Howe [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: mod_proxy does not maintain the request_rec-bytes_sent field. X-Send-Pr-Version: 3.110 Number: 6841 Category: mod_proxy Synopsis: mod_proxy does not maintain the request_rec-bytes_sent field. Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: apache Arrival-Date: Tue Nov 14 06:20:01 PST 2000 Closed-Date: Last-Modified: Originator: [EMAIL PROTECTED] Release:1.3.14 Organization: apache Environment: Linux mail.snert.net 2.0.34C52_SK #1 Tue Nov 30 18:14:40 PST 1999 mips unknown Description: A user reported a bug against mod_throttle claiming that mod_throttle failed to record the number of bytes sent when the request passed through mod_proxy. Apon debugging and examination of the mod_proxy source, I found that ap_proxy_send_fb() tracked and returned the number of bytes received/sent, but that NO ONE made use of the return value to update the request_rec's bytes_sent field. Find enclosed a one line change to src/modules/proxy/proxy_util.c that updates the request_rec. By making the change in ap_proxy_send_fb(), http and ftp response from the remote server or from the cache will all correctly update the request_rec so that other modules can make use of this information in the logging phase. How-To-Repeat: Fix: *** proxy_util.c.orig Tue Nov 14 14:34:42 2000 --- proxy_util.cTue Nov 14 14:49:25 2000 *** *** 618,623 --- 618,626 ap_bflush(con-client); ap_kill_timeout(r); + + r-bytes_sent += total_bytes_rcvd; + return total_bytes_rcvd; } Release-Note: Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, you need] [to include [EMAIL PROTECTED] in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as general/1098: or ] [Re: general/1098:). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] [apbugs address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ] -8-- -- Anthony C Howe+33 6 11 89 73 78 http://www.snert.com/ ICQ: 7116561 AIM: Sir Wumpus Microsoft (cough, sputter, spit, !@#$%) ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message---
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
On Wed, May 29, 2002 at 06:47:20PM +0200, Graham Leggett wrote: Thomas Eibner wrote: Anyone looked at the remaining open bugs in 1.3 and might want to include this patch (and bug)? Only if someone can verify that this patch actually does anything. The proxy has been largely rewritten since then, so this bug might not still be outstanding. There is a release coming out in another day or two, I am stuck offline - can someone take a look at this fix and see if it works...? Would it also be possible to have mod_proxy for 1.3 set the same X-Forwarded-* headers as the 2.0 proxy does? Need patches for this? I thought v1.3.24 already did this - don't remember if I added it to v1.3 as well, I am sure I did. Looking at apache-1.3 in cvs VS httpd-2.0 there seems to be a few changes, and the X-Forwarded-* headers are some of them. I have a patch ready if needed (with what I believe are your comments in it). -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/ !(C)http://copywrong.dk/ http://apachegallery.dk/ Putting the HEST in .COM http://www.hestdesign.com/
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
On Wed, May 29, 2002 at 07:10:25PM +0200, Graham Leggett wrote: Thomas Eibner wrote: Looking at apache-1.3 in cvs VS httpd-2.0 there seems to be a few changes, and the X-Forwarded-* headers are some of them. I have a patch ready if needed (with what I believe are your comments in it). Just checked - the X-Forwarded-For is definitely there in v1.3. Dunno about the send_bytes fix. Can someone check for me? Ah yes, X-Forwarded-For is there, but not the two others there is in 2.0 (X-Forwarded-Server and X-Forwared-Host) I read in the source that someone thinks it needs to go into the Via header instead. And as I can read from the source, X-Forwarded-For is only sent when it's a reverse proxy request in 2.0, and always sent in 1.3. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/ !(C)http://copywrong.dk/ http://apachegallery.dk/ Putting the HEST in .COM http://www.hestdesign.com/
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
Thomas Eibner wrote: Ah yes, X-Forwarded-For is there, but not the two others there is in 2.0 (X-Forwarded-Server and X-Forwared-Host) I read in the source that someone thinks it needs to go into the Via header instead. And as I can read from the source, X-Forwarded-For is only sent when it's a reverse proxy request in 2.0, and always sent in 1.3. Oh yes... I remember now (memory rusty). If you can get a patch in before tomorrow, should be cool :) Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
On Wed, May 29, 2002 at 07:20:17PM +0200, Graham Leggett wrote:
Thomas Eibner wrote:
Ah yes, X-Forwarded-For is there, but not the two others there is in
2.0 (X-Forwarded-Server and X-Forwared-Host) I read in the source that
someone thinks it needs to go into the Via header instead. And as I can
read from the source, X-Forwarded-For is only sent when it's a reverse
proxy request in 2.0, and always sent in 1.3.
Oh yes... I remember now (memory rusty). If you can get a patch in
before tomorrow, should be cool :)
Inline patch here, but I'm wondering if you want the X-Forwarded-For
header to be stuck inside the conditional too?
Index: proxy_http.c
===
RCS file: /home/cvspublic/apache-1.3/src/modules/proxy/proxy_http.c,v
retrieving revision 1.98
diff -u -r1.98 proxy_http.c
--- proxy_http.c21 Apr 2002 21:16:39 - 1.98
+++ proxy_http.c29 May 2002 17:04:38 -
-350,6 +350,20
* where the original request came from.
*/
ap_table_mergen(req_hdrs, X-Forwarded-For, r-connection-remote_ip);
+if (r-proxyreq == PROXY_PASS) {
+const char *buf;
+/* Add X-Forwarded-Host: so that upstream knows what the
+ * original request hostname was.
+ */
+if ((buf - ap_table_get(r-headers_in, Host))) {
+ap_table_mergen(req_hdrs, X-Forwarded-Host, buf);
+}
+/* Add X-Forwarded-Server: so that upstream knows what the
+ * name of this proxy server is (if there are more than one)
+ * XXX: This duplicates Via: - do we strictly need it?
+ */
+ap_table_mergen(req_hdrs, X-Forwarded-Server, r-server_hostname);
+}
/* we don't yet support keepalives - but we will soon, I promise! */
ap_table_set(req_hdrs, Connection, close);
--
Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/
mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
!(C)http://copywrong.dk/ http://apachegallery.dk/
Putting the HEST in .COM http://www.hestdesign.com/
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
Thomas Eibner wrote: Inline patch here, but I'm wondering if you want the X-Forwarded-For header to be stuck inside the conditional too? I think it should be... will sort this out later tonight or first thing tomorrow, have to leave the internet cafe now to fetch someone. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
a cache removal policy for mod_mem_cache
I'm not commiting this until .37 is out the door but I thought some people may be interested in this beforehand http://webperf.org/a2/v37/cache 4 new files (cache_cache.[ch] | cache_pqueue.[ch] ) and some minor mods on mod_cache.c/h the interesting mods are in mod_mem_cache ---Ian
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
On Wed, May 29, 2002 at 07:44:16PM +0200, Graham Leggett wrote: Thomas Eibner wrote: Inline patch here, but I'm wondering if you want the X-Forwarded-For header to be stuck inside the conditional too? I think it should be... will sort this out later tonight or first thing tomorrow, have to leave the internet cafe now to fetch someone. Good, there was a small mistake in the patch anyway. I'll setup a test for it later so I can see if it actually works (doh). -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/ !(C)http://copywrong.dk/ http://apachegallery.dk/ Putting the HEST in .COM http://www.hestdesign.com/
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
At 01:30 PM 05/29/2002, Thomas Eibner wrote:
Index: proxy_http.c
===
RCS file: /home/cvspublic/apache-1.3/src/modules/proxy/proxy_http.c,v
retrieving revision 1.98
diff -u -r1.98 proxy_http.c
--- proxy_http.c21 Apr 2002 21:16:39 - 1.98
+++ proxy_http.c29 May 2002 17:04:38 -
@@ -350,6 +350,20 @@
* where the original request came from.
*/
ap_table_mergen(req_hdrs, X-Forwarded-For,
r-connection-remote_ip);
+if (r-proxyreq == PROXY_PASS) {
+const char *buf;
+/* Add X-Forwarded-Host: so that upstream knows what the
+ * original request hostname was.
+ */
+if ((buf - ap_table_get(r-headers_in, Host))) {
I think this should be buf = instead of buf -.
--
Greg Marr
[EMAIL PROTECTED]
We thought you were dead.
I was, but I'm better now. - Sheridan, The Summoning
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
On Wed, May 29, 2002 at 02:02:53PM -0400, Greg Marr wrote:
At 01:30 PM 05/29/2002, Thomas Eibner wrote:
Index: proxy_http.c
===
RCS file: /home/cvspublic/apache-1.3/src/modules/proxy/proxy_http.c,v
retrieving revision 1.98
diff -u -r1.98 proxy_http.c
--- proxy_http.c21 Apr 2002 21:16:39 - 1.98
+++ proxy_http.c29 May 2002 17:04:38 -
-350,6 +350,20
* where the original request came from.
*/
ap_table_mergen(req_hdrs, X-Forwarded-For,
r-connection-remote_ip);
+if (r-proxyreq == PROXY_PASS) {
+const char *buf;
+/* Add X-Forwarded-Host: so that upstream knows what the
+ * original request hostname was.
+ */
+if ((buf - ap_table_get(r-headers_in, Host))) {
I think this should be buf = instead of buf -.
Yup, and:
+ap_table_mergen(req_hdrs, X-Forwarded-Server, r-server_hostname
Should be r-server-server_hostname too.
But it seems that getting the Host at this point is already to late.
buf contains the remote hostname here already.
--
Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/
mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
!(C)http://copywrong.dk/ http://apachegallery.dk/
Putting the HEST in .COM http://www.hestdesign.com/
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
On Wed, May 29, 2002 at 08:18:53PM +0200, Thomas Eibner wrote:
On Wed, May 29, 2002 at 02:02:53PM -0400, Greg Marr wrote:
At 01:30 PM 05/29/2002, Thomas Eibner wrote:
Index: proxy_http.c
===
RCS file: /home/cvspublic/apache-1.3/src/modules/proxy/proxy_http.c,v
retrieving revision 1.98
diff -u -r1.98 proxy_http.c
--- proxy_http.c21 Apr 2002 21:16:39 - 1.98
+++ proxy_http.c29 May 2002 17:04:38 -
-350,6 +350,20
* where the original request came from.
*/
ap_table_mergen(req_hdrs, X-Forwarded-For,
r-connection-remote_ip);
+if (r-proxyreq == PROXY_PASS) {
+const char *buf;
+/* Add X-Forwarded-Host: so that upstream knows what the
+ * original request hostname was.
+ */
+if ((buf - ap_table_get(r-headers_in, Host))) {
I think this should be buf = instead of buf -.
Yup, and:
+ap_table_mergen(req_hdrs, X-Forwarded-Server, r-server_hostname
Should be r-server-server_hostname too.
But it seems that getting the Host at this point is already to late.
buf contains the remote hostname here already.
Which was fixed by the s/-/=/, thanks Greg.
--
Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/
mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
!(C)http://copywrong.dk/ http://apachegallery.dk/
Putting the HEST in .COM http://www.hestdesign.com/
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself
Now is not the time to be adding in code whilly-nilly... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: cvs commit: apache-1.3/src/modules/standard mod_rewrite.c
On 29 May 2002 [EMAIL PROTECTED] wrote: martin 02/05/29 10:39:23 Modified:src CHANGES src/modules/standard mod_rewrite.c Log: Fix a problem in mod_rewrite which would lead to 400 Bad Request responses for rewriting rules which resulted in a local path. AHA!!! That would explain why I just yesterday had to close a bug report on 2.0 which complained about some (invalid) config that worked under 1.3 causing 400's under 2.0. I didn't understand how it could have ever worked under 1.3, but I didn't actually go look. Having that conditional backwards in 1.3 would definitely explain it. :)) Good catch. --Cliff
Re: a cache removal policy for mod_mem_cache
On Wed, 29 May 2002, Ian Holsman wrote: I'm not commiting this until .37 is out the door but I thought some people may be interested in this beforehand http://webperf.org/a2/v37/cache If you're going to commit it, just do it. That's what my preliminary tag was for... so I had a base from which to selectively include patches. When tagged, APACHE_2_0_37 will != HEAD. :) --Cliff
Re: cvs commit: apache-1.3/src/modules/standard mod_rewrite.c
On Wed, May 29, 2002 at 05:39:24PM -, [EMAIL PROTECTED] wrote: Fix a problem in mod_rewrite which would lead to 400 Bad Request responses for rewriting rules which resulted in a local path. diff -u -r1.176 -r1.177 I hand-checked the other changes that had sneaked into rev 1.176; only the two invocations of ap_os_is_path_absolute() were incorrect. In 2.0, they were correct since 21-Oct-01 already. Although this was a hasty 1.3.25 commit, I think I did the Right Thing. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: cvs commit: apache-1.3/src/modules/standard mod_rewrite.c
martin 02/05/29 10:39:23 Modified:src CHANGES src/modules/standard mod_rewrite.c Log: Fix a problem in mod_rewrite which would lead to 400 Bad Request responses for rewriting rules which resulted in a local path. It seems I did in fact transpose the tests... good call and thank you for your good eyes in resolving this bug. Bill
Re: mod_proxy and PR 10246 for 1.3.25
On Tue, May 28, 2002 at 12:47:17PM -0400, Jim Jagielski wrote: Looks interesting and useful... should we fold into 1.3 (and 2.0)? Second thoughts: * it would be nice if this functionality could be folded into AllowCONNECT. - AllowConnect currently accepts only ports (thus a misnomer, a better name might have been AllowConnectPorts). - I imagine an AllowConnect *:443 to allow just this port, to any IP AllowConnect hostname:* to allow connect to hostname, but any port AllowConnect * to undo the builtin 443 563 limit and allow connections to any port (is that a good idea?) AllowConnect *:*any IP, any port AllowConnect a.b.c.d:443 d.e.f.g:8443 ... to allow connections to the hosts in the list * Also, the C++ comments must be changed to C comments * an update for the manual must be written * it must be tested. The current patch compiles fine, and works, but makes access control overly complex (which it already was in the proxy anyways). For example, I have: ProxyConnAllow 139.25.72.3 172.25.124.236 AllowCONNECT 443 8443 8100 I only _want_ some of these pairs to work, and forbid others (like: 139.25.72.3:443 and 172.25.124.236:8443 are Ok, but 172.25.124.236:443 isn't) The current patch doesn't allow for this. Also, it adds another new directive to mod_proxy... Don't know what to suggest for 1.3.25 -- I'm going on vacation from 02-Jun thru 19-Jun and cannot help much. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
On Wed, May 29, 2002 at 02:57:27PM -, [EMAIL PROTECTED] wrote:
Ignore leading zeros when parsing hex value for chunk extensions.
+/* Skip leading zeros */
+while (*b == '0') {
+++b;
+}
+
while (apr_isxdigit(*b) (chunkbits 0)) {
This patch will IMHO not change anything at all. Leading zeros are
added by the while (apr_isxdigit..) loop by shifting 0 4 and adding 0.
They never produce any overflow condition, no matter how many there are.
But it might be interesting to check the current value of
chunksize within the loop:
while (apr_isxdigit(*b)) {
int xvalue = 0;
...set xvalue to the next hex digit, value 0 thru 15...
/* --- Add here: a check whether the chunk will overflow the limit */
if (chunksize ((limit_req_line + 15) 4))
signal an error;
chunksize = (chunksize 4) | xvalue;
++b;
}
But we need
a) an extra parameter to pass the limit's value
(something like r-server-limit_req_line or a new configurable
max.chunk size) and
b) an error condition (get_chunk_size() currently has none)
to signal such an error.
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
On Wed, May 29, 2002 at 10:07:46PM +0200, Martin Kraemer wrote:
On Wed, May 29, 2002 at 02:57:27PM -, [EMAIL PROTECTED] wrote:
Ignore leading zeros when parsing hex value for chunk extensions.
+/* Skip leading zeros */
+while (*b == '0') {
+++b;
+}
+
while (apr_isxdigit(*b) (chunkbits 0)) {
This patch will IMHO not change anything at all. Leading zeros are
added by the while (apr_isxdigit..) loop by shifting 0 4 and adding 0.
They never produce any overflow condition, no matter how many there are.
Actually, the theory is that we can only handle a known number of 4-bit
hex digits, so we ignore leading zeros before we start counting those
digits. If we use too many digits, we run out of chunkbits and detect
the overflow and return -1. If we use exactly the right amount of
digits, but overflow the sign bit, the result will be 0 (is this
a valid assumption?). So, if the result is negative, it overflowed.
-aaron
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
On Wed, May 29, 2002 at 06:28:24PM +0200, Thomas Eibner wrote: From: Anthony Howe [EMAIL PROTECTED] Subject: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3 Number: 6841 ap_kill_timeout(r); + + r-bytes_sent += total_bytes_rcvd; + Yes, the patch was correct (IMHO) and yes, I committed this one. About the X-Forwarded-* stuff: It's non-standard anyway (you can add any X-whatever header and still be RFC2616 compliant) so I'd rather not see it in 1.3 now (maybe in the next release ;-) I've seen proxies like squid hang because of nonstandard headers (proxy-connection: keep-alive) so I am not very fond of polluting the header namespace with more non-standard cruft. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Tagging releases
On Wed, May 29, 2002 at 02:40:12PM -0400, Cliff Woolley wrote: If you're going to commit it, just do it. That's what my preliminary tag was for... so I had a base from which to selectively include patches. When tagged, APACHE_2_0_37 will != HEAD. :) In the good old days, a tag was a tag was a tag. There was no preliminary tag which would then be moved to a different revision later on an ad-hoc basis. The way the httpd-2.0 releases work now are IMHO not very professional from a release management perspective, and users (on dev@) are easily confused by what's going on. I hereby propose: a) a CVS tag is *NEVER* moved. b) a Release tag is always created as a _branch_ tag first. (The tag name could be APACHE_2_0_47_Branch or similar) % cvs co httpd-2.0 % cd httpd-2.0 % cvs tag -b APACHE_2_0_47_Branch % cvs up -r APACHE_2_0_47_Branch c) Such a Release Branch Tag is therefore *atomic* relative to the Working Tree of the person who is tagging. Even if somebody commits in the very same moment of the Branch-Tagging, the tag is still set on whatever the person tagging had checked out. d) if fixes need to be made against such a Release Branch, then they are simply committed (on the branch). % cvs ci blurb.c But only a fraction of the changes made after tagging is relevant to fixing the Release. Only these fixes should be applied to the Branch. Or, if a fix is made on the branch first, it must also be applied to HEAD manually. e) when the tar ball has been built _and announced_, then a final release tag is set on the release _Revision_ (cvs tag without -b) % cvs tag APACHE_2_0_47 Such a tag can not be moved later. f) If another release should be necessary (without going to the next Apache version for some reason), another name is tagged _on_the_branch_: % cvs ci securityfix.c % cvs tag APACHE_2_0_47_SecurityFix1 (to be fleshed out in more detail if approved; especially tag naming) The result is reproducibility (the tag names never move their place) and easier collaboration (no more no commits during the next 8 hrs please). If people want the 2.0.47 release, they checkout APACHE_2_0_47. % cvs co -r APACHE_2_0_47 httpd-2.0 Such a copy cannot be used to commit changes (because a tag is a tag is a tag, and there cannot be two different versions under one name) If developers want to update the 2.0.47 (for developing and commiting a hypothetical security fix1) they checkout the Branch version: % cvs co -r APACHE_2_0_47_Branch httpd-2.0 Such a copy _can_ be modified, and changes can be committed. In ASCII graphics it could look similar to the appended example. What do you think about this proposal? Martin -- Head Branch 1 ! * 1.17 !\ ! \ ! \ ! \ Branch 1.17.2 aka. APACHE_2_0_47_Branch !\ ! \ ! \ ! * 1.17.2.1 (fix against 1.17) ! ! * 1.18 ! ! ! ! * 1.17.2.2 (2nd fix) ! ! later tagged APACHE_2_0_47 release tar ball * 1.19 ! ! * 1.17.2.3 (Security Fix applied) ! ! later tagged APACHE_2_0_47_SecurityFix1 release tar ball ! * 1.20 incorporating the fixes from the APACHE_2_0_47_Branch branch ! HEAD -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: Tagging releases
On Wed, May 29, 2002 at 11:20:43PM +0200, Kraemer, Martin wrote: ... I forgot to mention that, with Subversion, it's going to be completely different again. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: Tagging releases
On Wed, 29 May 2002, Martin Kraemer wrote: On Wed, May 29, 2002 at 02:40:12PM -0400, Cliff Woolley wrote: In the good old days, a tag was a tag was a tag. There was no preliminary tag which would then be moved to a different revision later on an ad-hoc basis. I never said it would be moved. I said ANOTHER tag would be done. Right now we have JCW_PRE_2037. Next we'll have JCW_PRE2_2037, then JCW_PRE3_2037. It's just a matter of release candidates in a way. Roy was very insistent upon this when we were in the 2.0.36 release cycle (and I agreed), but for 2.0.36 it was too late, we'd already bumped some tags. We agreed that from then on, some pre-tag would be done and we'd use multiple tags to specify subsequent candidates. When one of those is selected for release, it gets retagged as APACHE_2_0_xxx. We could just spew through version numbers and maybe the next version released after 2.0.36 is 2.0.48, but that doesn't make much sense from the users' perspective. a) a CVS tag is *NEVER* moved. That has already been agreed upon AFAIK. b) a Release tag is always created as a _branch_ tag first. (The tag name could be APACHE_2_0_47_Branch or similar) % cvs co httpd-2.0 % cd httpd-2.0 % cvs tag -b APACHE_2_0_47_Branch % cvs up -r APACHE_2_0_47_Branch -1. Please let's not go down the branch route. Merging sucks. We've agreed time and time again that we don't want to use CVS branches. e) when the tar ball has been built _and announced_, then a final release tag is set on the release _Revision_ (cvs tag without -b) % cvs tag APACHE_2_0_47 Such a tag can not be moved later. Except for the branch part, that has also already been agreed upon. f) If another release should be necessary (without going to the next Apache version for some reason), another name is tagged _on_the_branch_: % cvs ci securityfix.c % cvs tag APACHE_2_0_47_SecurityFix1 We have a hard enough time getting releases out, much less patchlevels. --Cliff
Re: [1.3] Proxy fixes and FWD: Re: [apache-modules] Setting bytes_sent in Request Record while generating all headers by myself in Apache 1.3]
On Wed, May 29, 2002 at 10:44:16PM +0200, Martin Kraemer wrote: Yes, the patch was correct (IMHO) and yes, I committed this one. About the X-Forwarded-* stuff: It's non-standard anyway (you can add any X-whatever header and still be RFC2616 compliant) so I'd rather not see it in 1.3 now (maybe in the next release ;-) My only reasoning for wanting it in was that it's the way it works in mod_proxy in 2.0. I've seen proxies like squid hang because of nonstandard headers (proxy-connection: keep-alive) so I am not very fond of polluting the header namespace with more non-standard cruft. Not good. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/ !(C)http://copywrong.dk/ http://apachegallery.dk/ Putting the HEST in .COM http://www.hestdesign.com/
RE: cvs commit: httpd-2.0 STATUS
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 00:16 Modified:.STATUS Log: I'm holding off on the pool patches until they settle down a bit. The bugs that were uncovered are independent of the hifree/reuse patch. They have been in there for a while. I'll be committing fixes in a moment. Sander
RE: cvs commit: httpd-2.0 STATUS
At 05:55 PM 5/29/2002, you wrote: On Wed, 29 May 2002, William A. Rowe, Jr. wrote: Cliff, in order to get together Sebastian's fixes for isapi, we need to roll up to the current thread_mutex code with the APR_THREAD_MUTEX_UNNESTED flag... could you fold those changes in along with the mod_isapi.c fixes, and the change to the mod_deflate.dsp to incorporate the inflation API? I'll incorporate the thread_mutex changes after I've tested them, but I will admit there are rather more /* XXX: implement this */ comments in there than I'd like to see under normal circumstances. Yes - however we used to assert that _DEFAULT was an unnested lock, but rather than return ENOTIMPL, Win32, OS2 and Netware blindly returned nested locks. That is a serious fault. Now _DEFAULT is platform's choice, _NESTED is implemented everywhere, and only _UNNESTED is is a new behavior/option and is only used in modules/arch/win32/mod_isapi.c so far. I'm sure someone will discover other locks that weren't supposed to be nested, they will fix these _DEFAULT cases, and then OS2/Netware will need to get on the ball or they will simply fail rather than proceeding with an inappropriate mutex. In the meantime, most _DEFAULTs throughout the server remain just fine for the 99% of cases. So ENOTIMPL only hits mod_isapi.c, and we went from /* XXX: aught to fix */ to returning ENOTIMPL, a safer behavior. As for the mod_deflate.dsp, I'm intentionally leaving that out because I'm intentionally leaving out the deflate_in filter for now. Very cool.
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On 30 May 2002 [EMAIL PROTECTED] wrote: striker 02/05/29 17:21:27 Modified:server/mpm/beos beos.c server/mpm/experimental/leader leader.c server/mpm/experimental/threadpool threadpool.c server/mpm/netware mpm_netware.c server/mpm/prefork prefork.c server/mpm/worker worker.c Log: Catch up with the apr_allocator_set_owner - apr_allocator_owner_set renames in APR. This requires an MMN bump (which is fine with me, since we've already done one in 2.0.37-dev, and I'm starting to see little point in going back now). If there are other renames of this sort, we should get them in all at once. Is the APR versioning system in place yet? --Cliff
Renames pending, WAS: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
From: Cliff Woolley [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 02:41 [...] Log: Catch up with the apr_allocator_set_owner - apr_allocator_owner_set renames in APR. This requires an MMN bump (which is fine with me, since we've already done one in 2.0.37-dev, and I'm starting to see little point in going back now). If there are other renames of this sort, we should get them in all at once. What about these: apr_pool_set_abort apr_pool_get_abort apr_pool_get_parent And the ones left in renames_pending? Also, Thom May posted a long list of suggestions a while back. Noone seems to have responded to that. Sander
[STATUS] (apache-1.3) Wed May 29 23:45:09 EDT 2002
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2002/05/29 19:56:21 $] Release: 1.3.25-dev: In development A release is proposed for end of May 2002. Jim volunteers to be RM. Baseline schedule is a TR on May 30, 2002 with a release on or about June 1, 2002. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19. Announced and released. 1.3.0: Tagged and rolled on June 1. Announced and released on the 6th. 2.0 : In alpha development, see httpd-2.0 repository RELEASE SHOWSTOPPERS: * Current vote on 2 PRs for inclusion: Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message [EMAIL PROTECTED]) RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * Backport of 2.0 ForceLanguagePriority directive /dist/httpd/contrib/patches/1.3/force_language_priority.patch Message-ID: [EMAIL PROTECTED] Status: * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: Pine.LNX.4.21.0102102350060.6815-20@desktop Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: [EMAIL PROTECTED] Status: Martin +1(concept) * Jayaram's patch (10/27/99) for bugfix to mod_autoindex IndexIgnore file-extension should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested) *
[STATUS] (httpd-2.0) Wed May 29 23:45:12 EDT 2002
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2002/05/30 02:55:56 $] Release: 2.0.37 : in development. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS CURRENT RELEASE NOTES: * 37 status: Cliff tagged JCW_PRE2_2037 on Wednesday. Some showstoppers remain, so there will be a PRE3 as well, probably Friday. Just wanted an intermediate milestone. RELEASE SHOWSTOPPERS: * HP/UX 10.20: compile breakage in APR. Looks like it should be easy to fix, probably just some extraneous #include's that are fouling things up. PR: 9457 * decide if the MMN bump was warranted * Win32: httpd won't start. There was a command line args problem that got fixed, but now something else is wrong. Status: one problem here might be a argument being returned from the rewrite_args hook getting caught by Jeff's patch to check args more strictly. Message-ID: [EMAIL PROTECTED] 00ca01c2033e$f1c54c10$a6271b09@sashimi [EMAIL PROTECTED] * CWD issues Message-ID: [EMAIL PROTECTED] [EMAIL PROTECTED] * To high-free patch or not to high-free patch? Status: Cliff is waiting until the recently uncovered bugs in this code get sorted out before including in 2.0.37. * Find a better name for ap_signal_server() Message-ID: [EMAIL PROTECTED] * server pushed CGI's not working. (Is this a showstopper??) PR: 8482 Message-ID: [EMAIL PROTECTED] CURRENT VOTES: * apachectl should revert to just being an init script and httpd.sh should be the wrapper for httpd which sources envvars and allows any options to be passed through +1: trawick * Should we always build [support*] binaries statically unless otherwise indicated? Message-ID: [EMAIL PROTECTED] +1: Ken, *wrowe [they are PITAs on OSX] -1: Justin, Ian * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, Jim, Justin Have 2 parents: +1: Jim -1: Justin, wrowe [for 2.0] +0: Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing) -0: Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * exec cmd and suexec arg-passing enhancements Status: Patches proposed Message-ID: [EMAIL PROTECTED] (see the proc.patch and suexec-shell.patch links in this message) * Get mod_cache/mod_mem_cache out of experimental (still some work items left to complete) * The 2.0.36 worker MPM graceless shutdown changes work but are a bit clunky on some platforms; eg, on Linux, the loop to join each worker thread seems to hang, and the parent ends up killing off the child with SIGKILL. But at least it shuts down. * --enable-mods-shared=foo1 foo2 is busted on Darwin. Pier posted a patch (Message-ID: [EMAIL
RE: Client socket
Tx a million for your reply. I need the actual socket that apache uses to communicate with the client in the php module. Is it available somewhere in the request_rec structure? I've been trying to get this for ages now. Tx, Vinod. --- Vinod Panicker [EMAIL PROTECTED] Sr. Software Designer Geodesic Information Systems Ltd. -Original Message- From: Tony Finch [mailto:[EMAIL PROTECTED]] On Behalf Of Tony Finch Sent: Wednesday, May 29, 2002 9:33 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Client socket On Wed, May 29, 2002 at 04:27:59PM +0530, Vinod Panicker wrote: This script I call from the browser, and everytime it displays a '3'. I even called it from different browser windows, still the same. That cant be alright since if the fd is 3 as shown in one browser window, it has to be something different in the other window since the browser defaults to a keep-alive connection, and the fd's have to be different. Each connection is handled in a different process and each process's fd 3 is different. If a process fork()s two children and each child accept()s a connection they will each receive a different connection but it will be allocated the same fd number in each child. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ CROMARTY: SOUTHEASTERLY VEERING SOUTHWESTERLY 5 OR 6, DECREASING 4. RAIN THEN SHOWERS. MODERATE BECOMING GOOD.
httpd-2.0 STATUS
* Port of mod_ssl to Apache 2.0: The current porting state is summarized in modules/ssl/README. The remaining work includes: (1) stablizing/optimizing the SSL filter logic (2) Enabling SSL extentions (3) Trying to seperate the https filter logic from mod_ssl - This is to facilitate other modules that wish to use the https filter or the mod_ssl logic or both as required. This is all so out of date, is modules/ssl/README even valuable anymore? Shall we dump this little section from STATUS altogether [the port is finished] and add new items in STATUS as we see them [e.g. number 3 above?] Bill
RE: httpd-2.0 STATUS
+1 (if it counts) -Madhu -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 10:43 PM To: [EMAIL PROTECTED] Subject: httpd-2.0 STATUS * Port of mod_ssl to Apache 2.0: The current porting state is summarized in modules/ssl/README. The remaining work includes: (1) stablizing/optimizing the SSL filter logic (2) Enabling SSL extentions (3) Trying to seperate the https filter logic from mod_ssl - This is to facilitate other modules that wish to use the https filter or the mod_ssl logic or both as required. This is all so out of date, is modules/ssl/README even valuable anymore? Shall we dump this little section from STATUS altogether [the port is finished] and add new items in STATUS as we see them [e.g. number 3 above?] Bill
Re: httpd-2.0 STATUS
On Thu, 30 May 2002, William A. Rowe, Jr. wrote: is modules/ssl/README even valuable anymore? yes. fine to remove the stale stuff, but not the whole damn thing. there was a useful roadmap of the source in there and everything that was in the TODO section is still valid: o SSL renegotiations in combination with POST request o Port all remaining code (code inside #if 0...#endif blocks) o Do we need SSL_set_read_ahead()? o the ssl_expr api is NOT THREAD SAFE. race conditions exist: -in ssl_expr_comp() if SSLRequire is used in .htaccess (ssl_expr_info is global) -is ssl_expr_eval() if there is an error (ssl_expr_error is global) o SSLRequire directive (parsing of) leaks memory o Diffie-Hellman-Parameters for temporary keys are hardcoded in ssl_engine_dh.c, while the comment in ssl_engine_kernel.c says: it is suggested that keys be changed daily or every 500 transactions, and more often if possible. o ssl_var_lookup could be rewritten to be MUCH faster o CRL callback should be pluggable o session cache store should be pluggable o init functions should return status code rather than ssl_die() o ssl_engine_pphrase.c needs to be reworked so it is generic enough to also decrypt proxy keys o the shmcb code should just align its memory segment rather than jumping through all the safe memcpy and memset hoops
