Re: Urgent Help required!
If this is indeed a follow-up to my question way back when about mod_rewrite, mod_proxy, and digest authentication, I was unable to find a real solution. What I ended up doing was excluding the digest authentication from proxying, and instead doing it on the forward facing server (the one doing the proxying). This worked because the back-end pages were accessible without authentication, but they used http_auth values to identify users for non-apache based authorization. On Wed, May 28, 2008 at 8:34 AM, ElizabethTown [EMAIL PROTECTED] wrote: Is anybody here? -- View this message in context: http://www.nabble.com/mod-proxy%2C-path-rewrite%2C-and-digest-authentication-tp16098622p17511628.html Sent from the Apache HTTP Server - Module Writers mailing list archive at Nabble.com. -- My Blogs: http://www.docunext.com/ http://www.albertlash.com/
blocking or non-blocking socket ?
Hello, I'm interested by the internal architecture of the mpm_worker in Apache; I've read some documentation available on the Internet (http://www.fmc-modeling.org/category/projects/apache/amp/Apache_Modeling_Project.html), I've looked at the source code but I still have one big question: is this mpm using blocking or non-blocking socket? I think it's non-blocking but I'd like to have a confirmation. Regards, Julien
Re: Empty Reason Phrase (BZ 44995/45092)
Jeff Trawick wrote: On Tue, May 27, 2008 at 3:29 PM, Rainer Jung [EMAIL PROTECTED] wrote: Jeff Trawick schrieb: On Tue, May 20, 2008 at 3:27 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 05/20/2008 08:52 PM, Jeff Trawick wrote: Do we really need to require the space in the case that the reason phrase is empty? No... Both sets of code should be changed to consider the space optional. We just need to make sure we generate the space in our response so some other software doesn't have to be so generous. I attached two patches against trunk to BZ 44995, one for the status_line validation in http_filters.c and one for the test when used in error pages in http_protocol.c. Backports should be straighforward, because the code didn't change locally. I didn't yet test thoroughly, but if you like them in principle I'll go through it. re: https://issues.apache.org/bugzilla/attachment.cgi?id=22019 I don't think r-status_line should be updated by this function (ap_send_error_response()). OK, so there are two cases which need clarification w.r.t. ap_send_error_response() in http_protocol.c: 1) status_line =NNN 3 digit status code without trailing space This would be non-conforming to RFC 2616. We correct it in validate_status_line() in http_filters.c but I neither know, if there is an order between ap_send_error_response() and validate_status_line(), nor if the status line could change in between. If we use the old behaviour, we simply switch to the standard 500 status line if we detect NNN in ap_send_error_response(). Anyone knowing more about the order of processing between ap_send_error_response() and validate_status_line() (which is called by basic_http_header_check(), which in turn is used inside ap_basic_http_header() and ap_http_header_filter())? Even if we correct the status_line here (adding a space), we still have to decide on the second case below. 2) status_line =NNN 3 digit status code with trailing space but no following reason phrase What should be used as a header in the error page body. Usually we use everything behind the space, which is an emptry string here. Before the patch we would switch to the standard status 500, although the status line was valid. Should we use something like Unknown Reason in the error page headline but keep status_line as is (NNN )? In this case I would also suggest to set the title of the page to NNN Unknown Reason instead of NNN .
Re: svn commit: r660749 - /httpd/httpd/branches/2.2.x/STATUS
On Tue, 27 May 2008 22:26:09 - [EMAIL PROTECTED] wrote: + rpluem says: Thanks. Sorry for being picky, but after revisiting the patch + again I ask myself how we can be sure that the chroot function is actually + present on the platform we compile. $ man chroot ... CONFORMING TO SVr4, SVID, 4.4BSD, X/OPEN. How many unix platforms support none of the above? Would #ifdef HAVE_UNISTD_H be an appropriate wrapper for this, or could you have a unistd without chroot? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: mod_wombat
Hi, * Matthew M. Burke [EMAIL PROTECTED] [2008-05-26 22:33:23]: 1) I can't seem to find the output from r:debug, r:info, etc. I'm running mod_wombat on a VirtualHost. I've looked at the log configured in httpd.conf and the log set inside the VirtualHost container but do not see any of the messages from the various logging functions. No errors, either. Any hints? I didn't try to reproduce the problem, but did you check your LogLevel ? - Maxime PS: for now, exams are preventing me for working even half-time on my SoC, but I hope to start working on all this very soon. -- Maxime Petazzoni http://www.bulix.org 06.71.50.63.63 signature.asc Description: Digital signature
Re: [PATCH] Response to TRACE garbled from EBCDIC platform
On Thu, May 15, 2008 at 01:54:35PM -0400, David Jones wrote: The response to TRACE when TraceEnable Off is not used on an EBCDIC platform is partially in ASCII and partially in EBCDIC (part readable, part garbage). In the 2.2.8 version I recently ported to a /390 machine, this error does not occur. Can it be that mod_charset_lite was not included? It appears as if you have a 2.2.7 apache. Did you try again with 2.2.8? What TRACE command did you send? I tried this: (where the 1st host is a /390 proxy, and the others are ASCII based test proxies): --snip-- % telnet d016ze04.mch.fsc.net 8000 Trying 172.25.81.13... Connected to d016ze04.mch.fsc.net. Escape character is '^]'. TRACE http://www.apache.org/ HTTP/1.1 Host: www.apache.org HTTP/1.1 200 OK Date: Tue, 27 May 2008 12:43:20 GMT Server: Apache/2.2.8 (Unix) Content-Type: message/http Via: 1.1 MHPAKAJC (NetCache NetApp/6.0.6), 1.1 pgtm0035.mch.fsc.net:82 (Apache/1.3.37) X-Cache: MISS from pgtm0035.mch.fsc.net Via: 1.1 deejai2.mch.fsc.net (Apache/2.2.9-dev) Via: 1.1 D016ZE04.mch.fsc.net (Apache/2.2.8) Transfer-Encoding: chunked f3 TRACE / HTTP/1.1 Host: www.apache.org Connection: keep-alive Via: 1.1 D016ZE04.mch.fsc.net (Apache/2.2.8), 1.1 deejai2.mch.fsc.net (Apache/2.2.9-dev), 1.1 pgtm0035.mch.fsc.net:82 (Apache/1.3.37), 1.1 MHPAKAJC (NetCache NetApp/6.0.6) 0 --snip-- One thing however that certainly differs between your apache and mine is the fact that I added a flag to request_rec that gets set whenever the server internally generates stuff. Mod_charset_lite then enforces a EBCDIC-NATIVE-to-ASCII conversion. Its definition looks similar to this: --- httpd-2.2.8.orig/include/httpd.hThu Nov 15 23:08:30 2007 +++ httpd-2.2.8/include/httpd.h Thu Jan 10 18:53:54 2008 @@ -1002,6 +1002,20 @@ struct request_rec { * record to improve 64bit alignment the next time we need to break * binary compatibility for some other reason. */ +#if APR_CHARSET_EBCDIC +/* + * Flag to indicate forced vs. automatic conversion of the + * response from the charset of the source code to ASCII. + * Set when the response body is coded in the + * implementation character set (i.e., the charset of the source + * code). This would get several different types of documents + * translated properly: mod_autoindex output, mod_status output, + * mod_info output, hard-coded error documents, etc. + * Used by mod_charset_lite to determine whether implicit + * conversions should be applied. + */ +int response_uses_implementation_charset; +#endif }; This flag gets set in: * mod_dav's dav_error_response(), dav_method_options() etc., * mod_example's x_handler(), * mod_autoindex's index_directory(), * mod_status's status_handler(), * mod_proxy_balancer.c balancer_handler(), and I had to rewrite mod_charset_lite somewhat to do the right thing with this flag (and with PUT/POST handling in general: the current mod_charset_lite does not properly convert uploaded entities according to their MIME type, it was designed mainly for download conversion). I intend to publish the patch for 2.3.x (and propose a backport for 2.2.x); if you are interested just let me know, so that I can separate it from my other changes made for my employer's 2.2.8 version. Your patch is IMO no longer needed when these changes are applied. HTH, Martin -- [EMAIL PROTECTED]| Fujitsu Siemens http://www.fujitsu-siemens.com/imprint.html | 81730 Munich, Germany
Re: svn commit: r661087 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/proxy_util.c
On 05/28/2008 11:11 PM, [EMAIL PROTECTED] wrote: Author: niq Date: Wed May 28 14:11:24 2008 New Revision: 661087 URL: http://svn.apache.org/viewvc?rev=661087view=rev Log: Introduce variable interpolation in reverse proxy configuration Modified: httpd/httpd/branches/2.2.x/CHANGES httpd/httpd/branches/2.2.x/STATUS httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml httpd/httpd/branches/2.2.x/include/ap_mmn.h httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy.c httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy.h httpd/httpd/branches/2.2.x/modules/proxy/proxy_util.c Modified: httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy.h URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy.h?rev=661087r1=661086r2=661087view=diff == --- httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy.h (original) +++ httpd/httpd/branches/2.2.x/modules/proxy/mod_proxy.h Wed May 28 14:11:24 2008 @@ -110,6 +110,7 @@ }; #define PROXYPASS_NOCANON 0x01 +#define PROXYPASS_INTERPOLATE 0x02 struct proxy_alias { const char *real; const char *fake; @@ -212,9 +213,19 @@ apr_array_header_t* cookie_domains; const apr_strmatch_pattern* cookie_path_str; const apr_strmatch_pattern* cookie_domain_str; +int interpolate_env; const char *ftp_directory_charset; } proxy_dir_conf; But now this is the *WRONG* order: interpolate_env *MUST* be the last element of proxy_dir_conf. Regards RĂ¼diger
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
Late reply on this -- I had to spend time on other projects. :) I have a dedicated test proxy set up now so it's easier to capture the correct packets now and experiment. Sounds you are just stuck in the middle trying to deal with a broken client. I thought you might be trying to actually implement the client software or something. Yes, sorry, I should have clarified that earlier. Sure, you can fix this. Just get in with a monkey wrench if you have to and force mod_proxy to honor 'Keep-Alive' for an OPTIONS request and the behavior should then be identical to the ( known good ) direct-to-IIS example. I am going to definitely try to do this now. Point me in the right direction maybe? Is there actually an Apache config option I can leverage for this or do I need to look to patch the mod_proxy source? PS: Still just curious. What is the HTTP/x.x value actually being sent by the The Treo for the exchange in question?. Is it the older HTTP/1.0 or is it actually requesting full HTTP/1.1 functionality? Sometimes that comes into play with this 'Keep-Alive' stuff. If it's sending HTTP/1.0 then perhaps mod_proxy is simply obeying strict standards and that's why it changes 'Keep-Alive' back to 'Close'. 'Keep-Alive' was not 'officially' part of the HTTP/1.0 specs. It just sort of 'crept in there' and was available BEFORE full implementation of HTTP/1.1. So there's still a lot of confusion out there and a lot of 'looking the other way' going on with regards to 'Keep-Alive'. Some code tries to be strict ( Apache, generally ) and others are 'loose' ( Microsoft/IIS? ). Example: MS Internet Explorer has always had an 'Advanced Option' which allows you to decide to use HTTP/1.1 for Proxy Connections but it is OFF by default. Default behavior for MSIE Proxy requests is to use the older HTTP/1.0. However... that doesn't mean it won't use Keep-Alive. It treats that part of the HTTP/1.1 spec as an exception. Apologies in advance if this is all just old news to you. On my own Microsft Windows Mobile Treo, however, this legacy Advanced Option is missing. The Pocket Internet Explorer Browser under Windows Mobile will ALWAYS send an HTTP/1.1 request. It is requesting HTTP/1.1. I'll paste the full conversation here which I just captured. This is from the Treo to and from the Proxy and again is with Apache 2.2.9 svn 659141 straight HTTP (no SSL). 1 OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1 MS-ASProtocolVersion: 2.5 Connection: Keep-Alive User-Agent: PalmOne-TreoAce/1.53 Host:redowadev.esri.com Cache-Control: no-cache Authorization: Basic stuff Content-Length: 0 4 HTTP/1.1 200 OK Date: Wed, 28 May 2008 22:52:00 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Public: OPTIONS, POST Allow: OPTIONS, POST MS-Server-ActiveSync: 6.5.7638.1 MS-ASProtocolVersions: 1.0,2.0,2.1,2.5 MS-ASProtocolCommands: Sync,SendMail,SmartForward,SmartReply,GetAttachment,GetHierarchy,CreateCollection,DeleteCollection,MoveCollection,FolderSync,FolderCreate,FolderDelete,FolderUpdate,MoveItems,GetItemEstimate,MeetingResponse,ResolveRecipients,ValidateCert,Provision,Search,Notify,Ping Content-Length: 0 Cache-Control: private Content-Type: text/html; charset=UTF-8 Connection: close 5 POST /Microsoft-Server-ActiveSync?Cmd=FolderSync[EMAIL PROTECTED]DeviceId=xx63DeviceType=PalmOneTreoAce HTTP/1.1 Content-Type: application/vnd.ms-sync.wbxml MS-ASProtocolVersion: 2.5 Connection: Keep-Alive User-Agent: PalmOne-TreoAce/1.53 Host:redowadev.esri.com Cache-Control: no-cache X-MS-PolicyKey: 0 Authorization: Basic stuff Content-Length: 13 ^^ This packet is never proxied on to the IIS server. Here is the proxy to OWA (IIS) server conversation: 2 OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1 Host: redowadev.esri.com MS-ASProtocolVersion: 2.5 User-Agent: PalmOne-TreoAce/1.53 Cache-Control: no-cache Authorization: Basic stuff X-Forwarded-For: 99.204.225.107 X-Forwarded-Host: redowadev.esri.com X-Forwarded-Server: redowadev.esri.com Connection: Keep-Alive Content-Length: 0 3 HTTP/1.1 200 OK Date: Wed, 28 May 2008 22:52:00 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Public: OPTIONS, POST Allow: OPTIONS, POST MS-Server-ActiveSync: 6.5.7638.1 MS-ASProtocolVersions: 1.0,2.0,2.1,2.5 MS-ASProtocolCommands: Sync,SendMail,SmartForward,SmartReply,GetAttachment,GetHierarchy,CreateCollection,DeleteCollection,MoveCollection,FolderSync,FolderCreate,FolderDelete,FolderUpdate,MoveItems,GetItemEstimate,MeetingResponse,ResolveRecipients,ValidateCert,Provision,Search,Notify,Ping Content-Length: 0 Cache-Control: private Content-Type: text/html ^^ IIS agrees to keep the connection alive. FWIW, this Treo doesn't appear to have too much in the way of advanced options to toggle how its HTTP client used in sync'ing behaves. Thanks again, Ray