Re: 1.3.31 regression affecting Front Page?
At 07:09 AM 5/28/2004, Jim Jagielski wrote: >I've backed out that patch and asked Rasmus to send a replacemnet >which addresses his specific problem but does not cause >the below behavior. > >I'm tempted to release 1.3.32... Collect another week or few of data on other problems first, perhaps? Once the replacement patch arrives - we have a home for this over in /dist/httpd/patches/apply_to_1_3_31/, right? I'd also like to see a few other minor quibbles fixed, like the change of canonical name behavior. I do have to wrap my head around that issue still. Bill
[PATCH] Bug #29003 IFModule Enhancements
I made a post on the 20th about this bug report.. And there is now a new patch available that Andre and I worked on that solves all the issues that I mentioned before in regards to static/prelinked modules. The patch IDs are 11685 and 11690, posted on 5/27 and 5/28 respectively. I would like feed back on the main patch, and for someone to test the win32 patch (requires 11685 be applied first). These patches are based off of CVS 2.1 HEAD. Right now I see the solution as non-interfering with the current configuration of apache, as a symbol name will never be the same as a filename, so ifmodule can handle both. And as such am bringing this patch up for vote. Regards, Edward
Re: FTP proxy broken for non-anonymous ftp in IE
At 10:10 AM 5/28/2004, John Wojtowicz wrote: >[...] the patch in question didn't account for the case where an ftp request >might be of the form ftp://[EMAIL PROTECTED] > >It also seems to hardcode the ftp sites port to 21 which is probably >acceptable, for most people, and doesn't pull the port from the URI. > >I have a patch fix that uses adds parsing for the username and the port >number from the request. This patch has been tested with mozilla and >works fine, but I.E. doesn't work for some reason. Did authenticated >FTP proxying ever work with mod_proxy and Internet Explorer? Microsoft, in it's all seeing all knowing benevolence, broke from RFC2616 and no longer allows proto:[EMAIL PROTECTED] mechanics in IE (at least, in HTTP.) This was done for the users of the world assaulted daily by http://[EMAIL PROTECTED]/ URL's. Although many of us think this is a *presentation* problem, they decided that it is a vulnerability and crippled the feature. Your patch sounds great, and it quite possibly did work in the past, but we don't expect to see this work from IE anymore, at least, not when it uses http proxy. Bill
[PATCH 1.3] Proxied Server:/Date: headers
I'd worked with some interesting java and cgi code which implements
proxy behavior, as opposed to using a compiled-in module such as
mod_proxy. In order to properly pass on the Server: and Date: headers
(which are owned by the origin server), this patch tests for the presence
of a Via: header, indicating the response is proxied.
If neither r->proxyreq nor a 'Via:' header exist, the server still overrides
the Server: and Date: responses, per RFC.
Comments appreciated.
Bill--- src/main/http_protocol.c15 Apr 2004 15:51:51 - 1.335
+++ src/main/http_protocol.c28 May 2004 18:00:10 -
@@ -1544,6 +1544,8 @@
API_EXPORT(void) ap_basic_http_header(request_rec *r)
{
char *protocol;
+const char *datestr = NULL;
+const char *server = NULL;
if (r->assbackwards)
return;
@@ -1569,20 +1571,29 @@
/* output the HTTP/1.x Status-Line */
ap_rvputs(r, protocol, " ", r->status_line, CRLF, NULL);
-/* output the date header */
-ap_send_header_field(r, "Date", ap_gm_timestr_822(r->pool, r->request_time));
+/* keep the set-by-proxy date header, otherwise
+ * generate a new server header */
+if (r->proxyreq || ap_table_get(r->headers_out, "Via")) {
+datestr = ap_table_get(r->headers_out, "Date");
+
+if (datestr && (ap_parseHTTPdate(datestr) == BAD_DATE)) {
+datestr = NULL;
+}
+}
+if (!datestr || !*datestr) {
+datestr = ap_gm_timestr_822(r->pool, r->request_time);
+}
+ap_send_header_field(r, "Date", datestr);
/* keep the set-by-proxy server header, otherwise
* generate a new server header */
-if (r->proxyreq) {
-const char *server = ap_table_get(r->headers_out, "Server");
-if (server) {
-ap_send_header_field(r, "Server", server);
-}
+if (r->proxyreq || ap_table_get(r->headers_out, "Via")) {
+server = ap_table_get(r->headers_out, "Server");
}
-else {
-ap_send_header_field(r, "Server", ap_get_server_version());
+if (!server || !*server) {
+server = ap_get_server_version();
}
+ap_send_header_field(r, "Server", server);
/* unset so we don't send them again */
ap_table_unset(r->headers_out, "Date");/* Avoid bogosity */
[PATCH 1.3] XtOffsetOf multiply defined
[Another patch already in use, to be applied Tuesday unless someone speaks up.] We've found cases where XtOffsetOf is already defined on some platforms - we have no business overriding this (if we wanted our own flavor, it aught to have been AP_ prefixed :-) Bill # # Some platforms have an XtOffsetOf macro already defined, # since we didn't namespace protect our flavor, use the # already-defined flavor. # --- src/include/ap_config.h 29 Mar 2004 17:33:52 - 1.336 +++ src/include/ap_config.h 17 May 2004 17:03:19 - @@ -1365,10 +1365,12 @@ #endif /* !CRAY */ +#ifndef XtOffsetOf #ifdef offsetof #define XtOffsetOf(s_type,field) offsetof(s_type,field) #else #define XtOffsetOf(s_type,field) XtOffset(s_type*,field) +#endif #endif /*
[PATCH 1.3] HPUX11 mmap & out-of-order fix
[I'm collecting and presenting a number of internal patches which have been used and deployed in production for some time now... I'll toss out as patches and commit Tuesday if I hear no objections. Feedback welcome.] When the ap_config.h logic for HPUX11 was added, that #elif case was inserted *after* testing for HPUX or HPUX10. It's entirely reasonable to find HPUX and HPUX11 definined by the compiler. This patch move HPUX11 ahead of the HPUX case, enables the HAVE_MMAP and USE_MMAP_FILES logic, and drops the misleading commented options. I've seen where USE_MMAP_SCOREBOARD has been un-commented without dropping USE_SHMGET_SCOREBOARD, and HAVE_PTHREAD_SERIALIZED_ACCEPT has been enabled without disabling HAVE_FCNTL_SERIALED_ACCEPT. The way these commented-out options were added was misleading. I didn't see such code in other paths, so dropping the comments seemed rational. I didn't enable USE_MMAP_SCOREBOARD since both work, and the Linux case prefers USE_SHMGET_SCOREBOARD where both alternatives exist. But, it has been tested, does work, and could be made the default if anyone offers an argument to change this. Bill --- src/include/ap_config.h 29 Mar 2004 17:33:52 - 1.336 +++ src/include/ap_config.h 17 May 2004 17:03:19 - @@ -189,6 +189,21 @@ #define SELECT_NEEDS_CAST #define HAVE_SYSLOG 1 +#elif defined(HPUX11) +#ifndef _HPUX_SOURCE +#define _HPUX_SOURCE +#endif +#define HAVE_SHMGET +#define USE_SHMGET_SCOREBOARD +#undef HAVE_GMTOFF +#define HAVE_FCNTL_SERIALIZED_ACCEPT +#define HAVE_MMAP +#define USE_MMAP_FILES +#define NO_KILLPG +#undef NO_SETSID +#define HAVE_SYSLOG +#define AP_ENABLE_EXCEPTION_HOOK + #elif defined(HPUX) || defined(HPUX10) #undef HAVE_GMTOFF #define NO_KILLPG @@ -205,24 +220,6 @@ typedef int rlim_t; #endif -#elif defined(HPUX11) -#ifndef _HPUX_SOURCE -#define _HPUX_SOURCE -#endif -#define HAVE_SHMGET -#define USE_SHMGET_SCOREBOARD -#undef HAVE_GMTOFF -#define HAVE_FCNTL_SERIALIZED_ACCEPT -/* feeling brave? want to try using POSIX mutexes? */ -/* #define HAVE_MMAP */ -/* #define USE_MMAP_SCOREBOARD */ -/* #define USE_MMAP_FILES */ -/* #define HAVE_PTHREAD_SERIALIZED_ACCEPT */ -#define NO_KILLPG -#undef NO_SETSID -#define HAVE_SYSLOG -#define AP_ENABLE_EXCEPTION_HOOK - #elif defined(AIX) #undef HAVE_GMTOFF #undef NO_KILLPG
FTP proxy broken for non-anonymous ftp in apache 1.3
Folks, I think a recent fix for proxypass with ftp broke non-anonymous proxying of FTP, in the Apache 1.3 proxy module. That fix for proxypass, took out the use of the parsed uri data in the request structure, and instead opted to parse out the FTP request explicitly. This is fine, but the patch in question didn't account for the case where an ftp request might be of the form ftp://[EMAIL PROTECTED] It also seems to hardcode the ftp sites port to 21 which is probably acceptable, for most people, and doesn't pull the port from the URI. I have a patch fix that uses adds parsing for the username and the port number from the request. This patch has been tested with mozilla and works fine, but I.E. doesn't work for some reason. Did authenticated FTP proxying ever work with mod_proxy and Internet Explorer? If there is interest in this patch I will post it to the mailing list. A colleague and I have also uncovered what appears to be a couple problems with the proxy cache code in 1.3. One appears to be with the ap_proxy_liststr function. The other appears to be in the revalidation code and concerns whether or not a cache file needs to be updated if ONLY the Date header has changed, and nothing else. John Wojtowicz Senior Secure Systems Engineer Trusted Computer Solutions 2350 Corporate Park Drive Suite 500 Herndon, VA 20171 P: 703-318-7134 F: 703-318-5041
Re: 1.3.31 regression affecting Front Page?
I've backed out that patch and asked Rasmus to send a replacemnet which addresses his specific problem but does not cause the below behavior. I'm tempted to release 1.3.32... Jeff Trawick wrote: > > This patch did it: > > http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173&r2=1.174 > > See also > > http://issues.apache.org/bugzilla/show_bug.cgi?id=29257 > http://www.rtr.com/fp2002disc/_disc2/0a71.htm > -- === 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: 1.3.31 regression affecting Front Page?
Hmm.. this was a patch suggested by Rasmus, iirc. Jeff Trawick wrote: > > Jeff Trawick wrote: > > This patch did it: > > > > http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173&r2=1.174 > > Backing out the patch also fixes a DAV regression. See > >http://issues.apache.org/bugzilla/show_bug.cgi?id=29237 > > > See also > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=29257 > > http://www.rtr.com/fp2002disc/_disc2/0a71.htm > > > -- === 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: 1.3.31 regression affecting Front Page?
On Fri, May 28, 2004 at 06:14:30AM -0400, Jeff Trawick wrote: > Jeff Trawick wrote: > >This patch did it: > > > >http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173&r2=1.174 > > Backing out the patch also fixes a DAV regression. See > > http://issues.apache.org/bugzilla/show_bug.cgi?id=29237 It's simple enough to reproduce; the request body is not getting discarded (since r->connection->keepalive = 0) for an error response on an actually-will-be-keptalive connection, e.g. the 401 response to a PROPFIND with a body. joe
Re: 1.3.31 regression affecting Front Page?
Jeff Trawick wrote: This patch did it: http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173&r2=1.174 Backing out the patch also fixes a DAV regression. See http://issues.apache.org/bugzilla/show_bug.cgi?id=29237 See also http://issues.apache.org/bugzilla/show_bug.cgi?id=29257 http://www.rtr.com/fp2002disc/_disc2/0a71.htm
