svn commit: r106320 - /httpd/mod_aspdotnet/trunk/Apache.Web/HostFactory.h
Author: wrowe
Date: Tue Nov 23 09:50:02 2004
New Revision: 106320
Modified:
httpd/mod_aspdotnet/trunk/Apache.Web/HostFactory.h
Log:
Clean up the only compile emit, and in the process create two
different warnings depending on which step fails.
Modified: httpd/mod_aspdotnet/trunk/Apache.Web/HostFactory.h
Url:
http://svn.apache.org/viewcvs/httpd/mod_aspdotnet/trunk/Apache.Web/HostFactory.h?view=diffrev=106320p1=httpd/mod_aspdotnet/trunk/Apache.Web/HostFactory.hr1=106319p2=httpd/mod_aspdotnet/trunk/Apache.Web/HostFactory.hr2=106320
==
--- httpd/mod_aspdotnet/trunk/Apache.Web/HostFactory.h (original)
+++ httpd/mod_aspdotnet/trunk/Apache.Web/HostFactory.h Tue Nov 23 09:50:02 2004
@@ -238,9 +238,19 @@
}
}
if (obj == NULL) {
-if (!ConnectHost(HostKey) || !(obj =
hostObj-get_Item(HostKey))) {
+if (!ConnectHost(HostKey)) {
Threading::Monitor::Exit(this);
-msg = String::Concat(LMount failure restarting host ,
+msg = String::Concat(LMount failed to connect
restarting host ,
+
__try_castString*(hostURI-get_Item(HostKey)),
+ L mapped to ,
+
__try_castString*(hostDir-get_Item(HostKey)));
+LogServerError(msg, APLOG_ERR, 0, rr-server);
+return 500;
+}
+obj = hostObj-get_Item(HostKey);
+if (!obj) {
+Threading::Monitor::Exit(this);
+msg = String::Concat(LMount failed to query
restarting host ,
__try_castString*(hostURI-get_Item(HostKey)),
L mapped to ,
__try_castString*(hostDir-get_Item(HostKey)));
Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php
Cliff Woolley wrote: On Tue, 23 Nov 2004, Joe Orton wrote: Discussion of whether or not it's useful to have PHP tests in httpd-test can take place on test-dev@, please send your comments there and I'll follow up. I actually think it's useful to have php tests in our suite, because having a large number of tests for a module as big as php helps to flush out bugs in httpd (and maybe apr). That would be even more the case if php's sapi module for httpd 2.x that worked as a filter were in a reasonable state... now that TestRunPHP and TestConfigPHP are complete, I was considering moving the existing php tests over to this new framework. the advantage is that each individual test would get an ok marker at a granular level, rather than a simple ok that represented, say, 5 tests together in a lump. how does this sound to everyone? I'd probably get to it sometime over the next two weeks, and I'd post a major diff before going forward. --Geoff
Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php
At 12:25 PM 11/23/2004, Cliff Woolley wrote: On Tue, 23 Nov 2004, Joe Orton wrote: Discussion of whether or not it's useful to have PHP tests in httpd-test can take place on test-dev@, please send your comments there and I'll follow up. I actually think it's useful to have php tests in our suite, because having a large number of tests for a module as big as php helps to flush out bugs in httpd (and maybe apr). That would be even more the case if php's sapi module for httpd 2.x that worked as a filter were in a reasonable state... I totally agree that regression testing is terrific. We gain alot knowing when our patches might break php. What I questioned was why we were doing the security validation of PHP when it's outside the scope of httpd, or isn't due to some interaction with httpd. I also questioned shoving scary security/CAN-2004-.t failures at our users. FIRST this should never have been in security/ - it should have been a php/ test. Again, this is not our security incident within httpd. Second, whenever we fail any CAN-2004-.t we must direct the user to some patch where they can remedy the situation. I'm sort of laughing that I spent 4 hours yesterday researching two vulns that many other engineers had spent 4 hours researching. The laughable thing - show me on www.php.net where they call out any patches for 4.3.x to these two incidents? It's akin to screaming FIRE in a crowded theater, when the doors are locked. Open up the doors first, then scream. Oh, just an aside, answering upgrade n-1.x to the latest n.0 release is no answer to a security incident. Didn't we just listen to a preso in Vegas decrying how 5.0 isn't 4.3? Bill
Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php
On Tue, Nov 23, 2004 at 12:55:16PM -0600, William Rowe wrote: What I questioned was why we were doing the security validation of PHP when it's outside the scope of httpd, or isn't due to some interaction with httpd. This is true for most of the functional tests of PHP in t/php/ which Covalent donated. I don't necessarily disagree, but I do I find it useful. Possibly these tests could go in the PHP test suite as well, I'm not sure. If that's your itch... I also questioned shoving scary security/CAN-2004-.t failures at our users. FIRST this should never have been in security/ - it should have been a php/ test. Again, this is not our security incident within httpd. I don't really care either way, smells like a freshly painted bikeshed to me ;) Second, whenever we fail any CAN-2004-.t we must direct the user to some patch where they can remedy the situation. I'm sort of laughing that I spent 4 hours yesterday researching two vulns that many other engineers had spent 4 hours researching. The laughable thing - show me on www.php.net where they call out any patches for 4.3.x to these two incidents? They don't, it was fixed silently, I mailed them about that but they didn't seem inclined to do anything about it. If you want to follow up on that some more, great, but ranting about it here won't make much difference. joe
Re: Bug #31228
On Mon, 22 Nov 2004 21:37:43 -0500, Garrett Rooney [EMAIL PROTECTED] wrote: Geoffrey Young wrote: Garrett Rooney wrote: Justin Erenkrantz wrote: --On Friday, September 17, 2004 1:07 PM -0400 Garrett Rooney [EMAIL PROTECTED] wrote: Could someone please take a look at bug 31228 in bugzilla? It's just adding a new response code (226) which is defined in rfc3229. I'm working on a module that implements a type of rfc3229 delta encoding, and it'd be nice if people didn't have to apply a patch to Apache in order to use it. FWIW, I looked at it the other night and I'm mildly iffy on adding it. Any particular reason? It seems like providing support for the response code specified in the RFC would only help encourage people to actually implement support for it in Apache, which seems like a good thing to me... provided that garrett's patch is technically the correct way to add a new status code to apache, and that RFC3229 went through the proper motions to capture exclusive use of 226 within http, I don't see any reason why 226 shouldn't be added in 2.1. This sort of got dropped on the ground once Justin told me how to make my module work without explicit support for the status code in the core, and it's totally my fault for not pressing it, but I'd still like to get this in or to hear what the reasoning for not including it is. So, uhh, ping? Any comments other than i'm iffy and is there any reason not to add it? +1 (concept; implementation not verified)
Re: mod_cgid, unix socket, ScriptSock directive
Jeff Trawick wrote: On Sat, 20 Nov 2004 12:11:34 -0500, Jeff Trawick [EMAIL PROTECTED] wrote: The ScriptSock directive must be used when there are two instances of the server with same ServerRoot. If it is omitted, symptoms may include . wrong credentials for CGIs . CGIs stop working for one server when other server is terminated It should be easy to avoid this configuration requirement by appending parent pid to the name of the unix socket which is used *when user didn't specify ScriptSock*, though there is slight migration concern in case administrator relies on name of unix socket for other reason (e.g., to use its existence as knowledge that mod_cgid is ready for business). It should be easy to catch such a misconfiguration by adding the parent pid to the CGI request sent over the Unix socket, and fail the request (and log appropriate message) if parent pid is wrong. code to check for the misconfiguration is small and is expected to be fool-proof (independent of what the user does); also, no way the change can result in stale unix sockets left around, unlike sticking the pid in the filename see patch in attachment Definitely +1 in concept. This will save someone a -lot- of time if they don't have a clue why their CGIs are failing and this is the problem. Bill
Re: More musings about asynchronous MPMs Re: Event MPM
Brian Pane wrote: Paul Querna wrote: Paul Querna wrote: A thread per-connection that is currently being processed. Note that this is not the traditional 'event' model that people write huge papers about and thttpd raves about, but rather a hybrid that uses a Worker Thread todo the processing, and a single 'event' thread to handle places where we are waiting for IO. (Currently accept() and Keep Alive Requests). Perhaps it needs a different name? (eworker?) A future direction to investigate would be to make all of the initial Header parsing be done Async, and then switch to a Worker thread to preform all the post_read hooks, handlers, and filters. I believe this could be done without breaking many 3rd party modules. (SSL could be a bigger challenge here...) Some academics have played with this model of a event thread + worker threads. Best I can find is the Java 'SEDA: An Architecture for Highly Concurrent Server Applications'. [1] Yeah, SEDA's model of processing stages--basically a succession of thread pools through which a request passes, each with a queue in front--looks like a promising way of mixing event-based and non-event-based processing. Thread context switches will suck performance out of any SEDA implementation. On a more general topic...and at the risk of igniting a distracting debate...does anybody else out there have an interest in doing an async httpd in Java? Sounds interesting to me though I doubt I would have much time to spend on it. There are a lot of reasons *not* to do so, mostly related to all the existing httpd-2.0 modules that wouldn't work. The things that seem appealing about trying a Java-based httpd, though, are: - The pool memory model at the core of httpd-1.x and -2.x isn't well suited to MPM designs where multiple threads need to handle the same connection--possibly at the same time, for example when a handler that's generating content needs to push output buckets to an I/O completion thread to avoid having to block the (probably heavyweight) handler thread or make it event-based. Garbage collection on a per-object basis would be a lot easier. In general you'll get better performance avoiding async/event driven i/o for i/o that can be completed quickly . And the httpd pools work perfectly for handling GET requests for smallish static files. GC per object is more difficult to get right imo. That said, I do understand your point; the httpd pool model falls down in the cases where you do need to pass a request to different threads. - Modern Java implementations seem to be doing smart things from a scalability perspective, like using kqueue/epoll/etc. They are getting better. - And (minor issue) it's a lot easier to refactor things in Java than in C, and I expect that building a good async MPM that handles dynamic content and proxying effectively will require a lot of iterations of design trial and error. For sure. Brian
Re: mod_cgid, unix socket, ScriptSock directive
On Tue, 23 Nov 2004 12:18:11 -0500, Bill Stoddard [EMAIL PROTECTED] wrote: Jeff Trawick wrote: On Sat, 20 Nov 2004 12:11:34 -0500, Jeff Trawick [EMAIL PROTECTED] wrote: The ScriptSock directive must be used when there are two instances of the server with same ServerRoot. If it is omitted, symptoms may include . wrong credentials for CGIs . CGIs stop working for one server when other server is terminated It should be easy to avoid this configuration requirement by appending parent pid to the name of the unix socket which is used *when user didn't specify ScriptSock*, though there is slight migration concern in case administrator relies on name of unix socket for other reason (e.g., to use its existence as knowledge that mod_cgid is ready for business). It should be easy to catch such a misconfiguration by adding the parent pid to the CGI request sent over the Unix socket, and fail the request (and log appropriate message) if parent pid is wrong. code to check for the misconfiguration is small and is expected to be fool-proof (independent of what the user does); also, no way the change can result in stale unix sockets left around, unlike sticking the pid in the filename see patch in attachment Definitely +1 in concept. This will save someone a -lot- of time if they don't have a clue why their CGIs are failing and this is the problem. I'm disappointed that configuration will still be required, but mod_cgid shouldn't be trying to solve such a configuration issue like automatically that when we're still left with LockFile and PidFile and logs and mutexes which have the same issue. (A more global approach could be useful however.)
Re: [PATCH] another mod_deflate vs 304 response case
On Mon, 22 Nov 2004, Roy T. Fielding wrote: Quoting William A. Rowe, Jr. [EMAIL PROTECTED]: Okay, but why the next three lines? Why would Content-Encoding: gzip *ever* be set on a 304? Because Content-* header fields in a 304 response describe what the response entity would contain if it were a 200 response. Therefore, the header field must be the same as it would be for a 200. The body must be dropped by the HTTP filter. Aha. Yeah okay that makes total sense. Thanks Roy. :)
Re: Bug #31228
So, uhh, ping? Any comments other than i'm iffy and is there any reason not to add it? +1 (concept; implementation not verified) here too. is this the most recent patch: http://issues.eu.apache.org/bugzilla/attachment.cgi?id=12746 ? if so, I'll try and review the implementation early next week and, save any objections, commit it to 2.1 if it looks ok to everyone. --Geoff
Re: Bug #31228
Geoffrey Young wrote: So, uhh, ping? Any comments other than i'm iffy and is there any reason not to add it? +1 (concept; implementation not verified) here too. is this the most recent patch: http://issues.eu.apache.org/bugzilla/attachment.cgi?id=12746 ? if so, I'll try and review the implementation early next week and, save any objections, commit it to 2.1 if it looks ok to everyone. Yes, I believe that is the current version of the patch, although I haven't tried to apply it to a current version of the httpd source, so it's possible there have been changes to that part of the tree in the meantime. If you have any trouble with it please let me know. Thanks, -garrett
Re: Whitespace strip filter for httpd v2.1
Ian Holsman wrote: In a nutshell, it is very hard to strip whitespace out of HTML, and have the resulting file still be as valid as the old one. Browsers are very forgiving on something and not on others. for example, you should not strip code inside of javascript, or 'pre' tags. The filter does not try to be content safe - otherwise the resulting processing burden would mean just use deflate and save yourself the hassle. It is assumed that an admin deploying the filter knows what they are doing when they do so. We ship with a module that changes case of the content - that will very likely break javascript too, but again, it assumes the user knows that it's for. Regards, Graham --
Re: 2.1.1 tarballs posted...
On Mon, Nov 22, 2004 at 10:06:02PM +, Matthieu Estrade wrote: Justin Erenkrantz wrote: http://httpd.apache.org/dev/dist/ Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.1.1 includes APR/APR-util 1.0.1 - we can adjust this later, if need be. 2.1.1 is currently at alpha level - if we get enough +1s (i.e. 3 or more), it can then be promoted to beta. -- justin +1 for beta One of the goals for releasing tar balls of the tree is to encourage feedback from *outside* the ASF. Before going beta, I suggest putting out a call for feedback from large implementers and deployers. I have a feeling that many lurk on this list and their experiences with the tarballs leading up to a release are very, very important. Cheers, Glenn
Re: [PATCH] another mod_deflate vs 304 response case
On Mon, Nov 22, 2004 at 11:40:29PM -0800, Roy T. Fielding wrote: Quoting William A. Rowe, Jr. [EMAIL PROTECTED]: Okay, but why the next three lines? Why would Content-Encoding: gzip *ever* be set on a 304? Because Content-* header fields in a 304 response describe what the response entity would contain if it were a 200 response. Therefore, the header field must be the same as it would be for a 200. The body must be dropped by the HTTP filter. That seems at odds with what 304 states unless I'm missing something? 10.3.5 says you MUST NOT or SHOULD NOT send any entity headers with a 304 except those explictly mentioned, which means the only Content-* header which should be sent is a Content-Length. I could interpret that paragraph to be talking only about caches, but this is exactly the logic which 1.3 and 2.0 implement as special case for a 304 response. joe
Re: [PATCH] another mod_deflate vs 304 response case
On Tue, Nov 23, 2004 at 07:51:19PM +, Joe Orton wrote: On Mon, Nov 22, 2004 at 11:40:29PM -0800, Roy T. Fielding wrote: Quoting William A. Rowe, Jr. [EMAIL PROTECTED]: Okay, but why the next three lines? Why would Content-Encoding: gzip *ever* be set on a 304? Because Content-* header fields in a 304 response describe what the response entity would contain if it were a 200 response. Therefore, the header field must be the same as it would be for a 200. The body must be dropped by the HTTP filter. That seems at odds with what 304 states unless I'm missing something? RFC2616
Re: Possible leak in core_output_filter()
On Tue, 23 Nov 2004, Ronald Park wrote: Now, for the bad news: we don't know if there's a specific single request that creates the problem. In fact, given that it mostly runs Blah, I was afraid of that. :-/ Now for the good news: we can probably run in production with debugging enabled (the overhead for extra debug code executing is probably negligible compared to overall download time for these huge files :D). So I'll see about getting that out there and report back with any findings. Okay, cool. You know, it would be really useful if there were a module that could track memory leaks related to buckets. I'm envisioning something like this: It has an input filter and an output filter. The input filter logs the request headers (let's just say no content body for the sake of simplicity), and the output filter logs the response. But for each one, what I'm more interested in than the content itself is that dump_brigade-style knowledge of what data was in what buckets, how big and of what type those bucket are, and which buckets were in the same brigade as opposed to separate brigades. So basically the output filter would just insert itself right above the core_output_filter and log all the buckets that fly by. It wouldn't be able to log the data contents of all bucket types without modifying the bucket (eg, file buckets), but like I say, I'm more interested in knowing the structure of the data than the data itself. The additional useful bit of information would be a log of what the RSS of the process was at the end of each request. I don't know if there's an easy way to get that information, but man would it be useful... --Cliff
Re: Possible leak in core_output_filter()
On Tue, 23 Nov 2004, Jim Jagielski wrote: http://www.apache.org/~jim/mod_dumpio.c Yeah. :-) But mod_dumpio calls apr_bucket_read() unconditionally on data buckets, which is exactly what I *don't* want it to do. Because that modifies the contents of the brigade. The module I'm looking for needs to be completely transparent. But it's a very good start. :-)
Re: Moving some files around?
At 05:39 PM 11/23/2004, Justin Erenkrantz wrote: There are some files that have content that have nothing to do with their name. And that annoys me to no end. Since we're now using a version control system that supports renames (oh yay!), any support for refactoring some files? My preliminary hit list contains: server/core.c: the core_input/output_filter-modules/filters/core.c *or* server/core_filters.c (server/core.c is 150k. Yikes!)\ Sounds like multiple files to me. Some of those are tied with... server/request.c: ap_directory_walk/ap_location_walk/ap_file_walk-server/walk.c leave location_walk - it has NOTHING to do with files. The directory/file walk corresponds to the core output filter. Is it time to create modules/ storage/ filesystem/ [sql/] [zip/] etc for different storage managers? Any walks.c / handler.c / etc would be associated to one specific backend manager. modules/http/http_protocol.c: ap_http_filter-modules/http/http_filter.c yup ap_http_header_filter-modules/http/http_filter.c hmmm. Do we want to? or do we want to combine into one source? ap_byterange_filter-modules/http/byterange_filter.c urp. I'm not 100% certain we want the byterange filter in the same context as the http protocol. Would be -so- nice to abstract this so it was generic to potentially multiple protocols which all needed support for partial results by range. modules/http/http_core.c: chunk_filter-modules/http/chunk_filter.c Chunking - most http. Good call. Bill
Re: Possible leak in core_output_filter()
One thing I was hoping is that, if bundled it, people can add the kind of features they need. It was designed for a simple and clear purpose, but there is more that it can, and should, do :) Cliff Woolley wrote: On Tue, 23 Nov 2004, Jim Jagielski wrote: http://www.apache.org/~jim/mod_dumpio.c Yeah. :-) But mod_dumpio calls apr_bucket_read() unconditionally on data buckets, which is exactly what I *don't* want it to do. Because that modifies the contents of the brigade. The module I'm looking for needs to be completely transparent. But it's a very good start. :-) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: Moving some files around?
--On Tuesday, November 23, 2004 6:06 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: server/core.c: the core_input/output_filter-modules/filters/core.c *or* server/core_filters.c (server/core.c is 150k. Yikes!)\ Sounds like multiple files to me. Some of those are tied with... server/request.c: ap_directory_walk/ap_location_walk/ap_file_walk-server/walk.c leave location_walk - it has NOTHING to do with files. The directory/file walk corresponds to the core output filter. Really? Why would core_output_filter correspond to a file? I'm not seeing the connection there. Should we just leave ap_location_walk in server/request.c? Although, I can't see why that makes much sense. Is it time to create modules/ storage/ filesystem/ [sql/] [zip/] etc for different storage managers? Perhaps. I know we've talked about re-abstracting the backend layer. Now that we have a decent SCM system, we can really play around with this without fear of CVS screwing things up. =) Any walks.c / handler.c / etc would be associated to one specific backend manager. *nod* modules/http/http_protocol.c: ap_http_filter-modules/http/http_filter.c yup ap_http_header_filter-modules/http/http_filter.c hmmm. Do we want to? or do we want to combine into one source? We could put it into http_header_filter.c (or header_filter.c) - but that seems a bit overkill. ap_byterange_filter-modules/http/byterange_filter.c urp. I'm not 100% certain we want the byterange filter in the same context as the http protocol. Would be -so- nice to abstract this so it was generic to potentially multiple protocols which all needed support for partial results by range. It has a lot of HTTP specific things in it - i.e. how to parse the ranges and indicate the ranges. So, as it's written right now, I believe that, yes, it's very HTTP-specific. modules/http/http_core.c: chunk_filter-modules/http/chunk_filter.c Chunking - most http. Good call. If I don't get any complaints, I'll try to tackle the re-org where we have consensus this weekend. And leave those that we're unsure of for later discussion. -- justin
Home for mod_dumpio was Re: Possible leak in core_output_filter()
--On Tuesday, November 23, 2004 7:54 PM -0500 Jim Jagielski [EMAIL PROTECTED] wrote: One thing I was hoping is that, if bundled it, people can add the kind of features they need. It was designed for a simple and clear purpose, but there is more that it can, and should, do :) I think mod_dumpio would be an excellent candidate to live in modules/test. That strikes me as the cleanest location for it. -- justin
Re: Moving some files around?
At 10:37 PM 11/23/2004, Justin Erenkrantz wrote: --On Tuesday, November 23, 2004 6:06 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: server/request.c: ap_directory_walk/ap_location_walk/ap_file_walk-server/walk.c leave location_walk - it has NOTHING to do with files. The directory/file walk corresponds to the core output filter. Really? Why would core_output_filter correspond to a file? I'm not seeing the connection there. The core handler i mean. The core handler only serves files. Bill
Re: Moving some files around?
At 06:06 PM 11/23/2004, William A. Rowe, Jr. wrote: ap_byterange_filter-modules/http/byterange_filter.c urp. I'm not 100% certain we want the byterange filter in the same context as the http protocol. Would be -so- nice to abstract this so it was generic to potentially multiple protocols which all needed support for partial results by range. Let me rephrase... the actual chunks (perhaps as part of a meta data chunk which describe them) would be nice to have generic. The processing and range selection for http obviously belong as you proposed. Perhaps move it all here, and refactor later into some generic response splitting mechanism. This does fit right along with... modules/http/http_core.c: chunk_filter-modules/http/chunk_filter.c Chunking - most http. Good call.
