Re: [PATCH] mod_negotiation.c
At 07:44 PM 10/25/2002, you wrote: >[ Simply trying again; or according to Jeff: nag, nag, nag ;-) ] > >If you use the "body" feature in type map files, the MIME-headers >currently are set dependant on what (mostly) type_checker says about the >type map file. > >The attached patch sets the MIME-type, charset, content-language and >content-encoding of a negotiated type-map body. Thus you can hold >different types, languages etc. inside the same file, for example: Nice! Thanks, I'll look and commit soon if nobody beats me to it.
Re: SOS! HELP- APACHE PROCESS PROBLEM
At 07:04 PM 10/25/2002, Jeff Trawick wrote: >"Chandragupt" <[EMAIL PROTECTED]> writes: > >> Hi, >> >> We have developed a BioInformatics Web based Application using >> CGIC , Linux and Apache as the webserver. We are using MySQL >> database for data handling. >> We have run into a problem wherein if the browser which has sent >> the request to Apache is closed in between a process, the process >> continues to run instead of being terminated. This causes the >> queuing of unwanted processes (both for Apache and MySQL). > >isn't this like PR 8388? > >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8388 > >Can the CGI write an HTML comment to the browser fairly regularly to >cause Apache to detect when the connection is reset? Wouldn't that >abort the connection and cause the CGI to get cleaned up? > >How else would Apache notice? What about simply writing 0 bytes to the socket periodically? Would that catch the disconnect? Bill
[PATCH] mod_negotiation.c
[ Simply trying again; or according to Jeff: nag, nag, nag ;-) ]
If you use the "body" feature in type map files, the MIME-headers
currently are set dependant on what (mostly) type_checker says about the
type map file.
The attached patch sets the MIME-type, charset, content-language and
content-encoding of a negotiated type-map body. Thus you can hold
different types, languages etc. inside the same file, for example:
--8<---[ typemap.var ]---
Content-language: de
Content-type: text/html; charset=ISO-8859-1
Body:--dehtml--
[german text/html document]
--dehtml--
Content-language: de
Content-type: application/xhtml+xml; charset=UTF-8
Body:--dexml--
[german application/xhtml+xml document; utf-8 encoded]
--dexml--
Content-language: en
Content-type: text/plain; charset=us-ascii
Body:--en--
[english text/plain document]
--en--
--8<---[ typemap.var ]---
The information will only be set if available, of course.
nd
--
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;
# André Malo # http://www.perlig.de #
Index: mod_negotiation.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_negotiation.c,v
retrieving revision 1.107
diff -u -r1.107 mod_negotiation.c
--- mod_negotiation.c 9 Aug 2002 19:21:57 - 1.107
+++ mod_negotiation.c 26 Oct 2002 00:29:52 -
@@ -2841,6 +2841,33 @@
*/
apr_table_setn(r->headers_out, "Accept-Ranges", "bytes");
ap_set_content_length(r, best->bytes);
+
+/* set MIME type and charset as negotiated */
+if (best->mime_type && *best->mime_type) {
+if (best->content_charset && *best->content_charset) {
+ap_set_content_type(r, apr_pstrcat(r->pool,
+ best->mime_type,
+ "; charset=",
+ best->content_charset,
+ NULL));
+}
+else {
+ap_set_content_type(r, apr_pstrdup(r->pool, best->mime_type));
+}
+}
+
+/* set Content-language(s) as negotiated */
+if (best->content_languages && best->content_languages->nelts) {
+r->content_languages = apr_array_copy(r->pool,
+ best->content_languages);
+}
+
+/* set Content-Encoding as negotiated */
+if (best->content_encoding && *best->content_encoding) {
+r->content_encoding = apr_pstrdup(r->pool,
+ best->content_encoding);
+}
+
if ((res = ap_meets_conditions(r)) != OK) {
return res;
}
Re: cvs commit: httpd-2.0/modules/loggers mod_logio.c
On Fri, 2002-10-25 at 16:52, [EMAIL PROTECTED] wrote: > Note: This works by adding a flush bucket to each response when > mod_logio is used; the side-effect is that pipelined responses > get broken up into separate network writes per request (but there's > no impact on pipelining when mod_logio is not enabled). I have found (on RedHat 7.3, vanilla kernel 2.4.19) that although the network writes are separate (in Apache) due to flushing, the data is usually sent out in a single packet when possible. I guess Nagle kicks in... Bojan
Re: SOS! HELP- APACHE PROCESS PROBLEM
"Chandragupt" <[EMAIL PROTECTED]> writes: > Hi, > > We have developed a BioInformatics Web based Application using > CGIC , Linux and Apache as the webserver. We are using MySQL > database for data handling. > We have run into a problem wherein if the browser which has sent > the request to Apache is closed in between a process, the process > continues to run instead of being terminated. This causes the > queuing of unwanted processes (both for Apache and MySQL). isn't this like PR 8388? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8388 Can the CGI write an HTML comment to the browser fairly regularly to cause Apache to detect when the connection is reset? Wouldn't that abort the connection and cause the CGI to get cleaned up? How else would Apache notice? Note that there was various streaming breakage until recently :( -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: response to comments re: API changing
Jeff Trawick <[EMAIL PROTECTED]> writes: > Carla Schroder <[EMAIL PROTECTED]> writes: > > > I'd like to hear from the actual developers on this! I read back several > > months in the list archives, to get some background. > > Technically, the API changes have been pretty minor. A module that > was working with alpha/beta Apache 2 at the beginning of 2001 could be (whoops, I meant to say "2002" instead of "2001"... not that it is *too* far off as written :) ) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: mod_logio patch testing Re: [STATUS] (httpd-2.0) Wed Oct 2323:45:19 EDT 2002
On Fri, 2002-10-25 at 15:31, Brian Pane wrote: > The only test case in which mod_logio didn't report as small a > byte count as expected was when I used telnet as the client and > stopped it (with ctrl-C) while the server was still sending the > response. A syscall trace on the server showed that, after I > interrupted telnet, the httpd did the remainder of its sendfile > calls (each one of which managed to send the next 48KB of the > requestd file; that appears to be a kernel limit) very, very > quickly. I think that's just because telnet did a half-close > and continued reading and discarding data until the server > closed its end of the connection before actually exiting. I have observed the same. However, if I closed xterm in which telnet was running, instead of pressing Ctrl-C, the behaviour would change and sizes were different. I agree with you that telnet probably continued reading, although not displaying it. There is no way an 80 MB file (in my test) could fly by my eyes that quickly :-) Bojan
Re: [PATCH]: Counting I/O with FLUSH and OFN (no MMN bump)
On Fri, 2002-10-25 at 17:01, Brian Pane wrote: > Tested and committed. Thanks! Thanks. Bojan
Re: [PATCH]Question - regarding modssl_PEM_read_bio_X509
"MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <[EMAIL PROTECTED]> writes: > Oh !!.. That is correct. The SSL_LIBRARY_VERSION is only defined by the > ssl_util_ssl.h. > (sorry) "make clean && make" after changing a header file and before sharing with the world does wonders :) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: [PATCH]Question - regarding modssl_PEM_read_bio_X509
Oh !!.. That is correct. The SSL_LIBRARY_VERSION is only defined by the ssl_util_ssl.h. (sorry) -Madhu > -Original Message- > From: Jeff Trawick [mailto:trawick@;attglobal.net] > Sent: Friday, October 25, 2002 3:10 PM > To: [EMAIL PROTECTED] > Subject: Re: [PATCH]Question - regarding modssl_PEM_read_bio_X509 > > > "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" > <[EMAIL PROTECTED]> writes: > > > -#define modssl_PEM_read_bio_X509 PEM_read_bio_X509 > > +#if (SSL_LIBRARY_VERSION < 0x00904000) > > +#define modssl_PEM_read_bio_X509(b, x, cb, arg) > PEM_read_bio_X509(b, x, cb) > > +#else > > +#define modssl_PEM_read_bio_X509(b, x, cb, arg) > PEM_read_bio_X509(b, x, cb, > > arg) > > +#endif > > I had to change the patch to look at OPENSSL_VERSION_NUMBER instead of > SSL_LIBRARY_VERSION... > > this section of ssl_toolkit_compat.h has the former defined but not > the latter... mod_ssl wouldn't compile for me without this change... > > > > > The following patch does something similar, and also > changes one other place > > in ssl_util_ssl.c where PEM_read_bio_X509 was still being used. > > fyi... your patch wouldn't apply because of some wrapped lines... > e-mail client setting on line wrap incorrect? > > patch committed! > > > -- > Jeff Trawick | [EMAIL PROTECTED] > Born in Roswell... married an alien... >
Re: [PATCH]Question - regarding modssl_PEM_read_bio_X509
"MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <[EMAIL PROTECTED]> writes: > -#define modssl_PEM_read_bio_X509 PEM_read_bio_X509 > +#if (SSL_LIBRARY_VERSION < 0x00904000) > +#define modssl_PEM_read_bio_X509(b, x, cb, arg) PEM_read_bio_X509(b, x, cb) > +#else > +#define modssl_PEM_read_bio_X509(b, x, cb, arg) PEM_read_bio_X509(b, x, cb, > arg) > +#endif I had to change the patch to look at OPENSSL_VERSION_NUMBER instead of SSL_LIBRARY_VERSION... this section of ssl_toolkit_compat.h has the former defined but not the latter... mod_ssl wouldn't compile for me without this change... > > The following patch does something similar, and also changes one other place > in ssl_util_ssl.c where PEM_read_bio_X509 was still being used. fyi... your patch wouldn't apply because of some wrapped lines... e-mail client setting on line wrap incorrect? patch committed! -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] Try to use OPENSSL_free instead of free
"MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <[EMAIL PROTECTED]> writes: > Based on Nadav Har'El's e-mail on the mod_ssl community > (http://marc.theaimsgroup.com/?l=apache-modssl&m=103540998016916&w=2), > here's a patch for 2.0's mod_ssl. committed, thanks! -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
[EMAIL PROTECTED] writes: > gregames2002/10/25 11:25:12 > > Modified:modules/http http_protocol.c > Log: > don't apply byte ranges to redirects, error documents, etc. This needs to be listed in CHANGES. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PROPOSAL] make child processes more awareable
"Mladen Turk" <[EMAIL PROTECTED]> writes: > Hi, > > This proposal is from the module developer point of view, so it might be > totally wrong from the server one. Can't some of this info be gleaned from ap_mpm_query()? Have you looked at that? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: response to comments re: API changing
Carla Schroder <[EMAIL PROTECTED]> writes: > I'd like to hear from the actual developers on this! I read back several > months in the list archives, to get some background. Technically, the API changes have been pretty minor. A module that was working with alpha/beta Apache 2 at the beginning of 2001 could be made to work with the current release pretty easily. If a module doesn't work with Apache 2 now, it is because there is a lack of serious interest on the part of the module authors (which of course is everybody's option). Almost all of the pain with the supposedly volatile API has been experienced by the end users, who may want to pick up fixes or enhancements to Apache without recompiling 3rd-party modules, and who have gotten bit frequently because binary compatibility is lost as soon as any aspect of the API is changed, whether or not it matters to their set of modules. It looks like we will address that with Apache 2.something releases which maintain binary compatibility with 2.0.41+ so that module recompiles are not needed for quite a while. So I hope the pain is over for users who are happy with the current function but still need to pick up future critical fixes without having to rebuild their modules. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: response to comments re: API changing
My comments... > Hello excellent Apache developers, > > I am writing a feature on Apache 2 for crossnodes.com. It will cover new > features, and quotes from users on why they are, or are not, > upgrading from > 1.3. (Besides 'if it ain't broke don't fix it') > > Would any of you care to address the following comment? This is > from the IT > director at a local ISP. Is this really an issue? > > "We are already using it for several sites.the biggest > problem that we > (and many others) have with deploying it everywhere is that the > API hasn't > yet stabilized, so > modules, such as PHP, have to be recompiled and often slightly modified to > get them to work every time Apache issues a new release. This is a pain as > we often have to wait for days or weeks before all of modules that we may > want to use have instructions on what to modify. > > "We are apprehensive about using it in shared hosting because we don't > consider it release-quality software. The quality of Apache 2.0 is quite good and -much- higher quality than most corporate .0 release software packages. Ive seen 2.0 with the worker MPM put under some very heavy loads on 8 way AIX machines and it holds up very well. apache.org runs 2.0 (prefork MPM) very reliably and has been for well over a year. I am sure other will chime in with their experiences. > We and many others > (including the PHP > development team) feel the Apache Software Foundation released it > prematurely. Most notably, they continue to change core APIs on point > releases, an established no-no in the open source development paradigm for > supposed stable, released software." > > I'd like to hear from the actual developers on this! I read back several > months in the list archives, to get some background. > The creeping API and the resultant lack of 3rd module support is true. We hope to start a stable branch of Apache 2 in the near future with the aim of keeping the API stable enough to encourage 3rd party modules authors to begin supporting Apache 2. If you need to use mod_perl, mod_php, etc and you are not comfortable with compiling and possibly modifying the source code of these modules yourself, you better stay away from 2.0 for now. > Thanks much, > Carla Bill
response to comments re: API changing
Hello excellent Apache developers, I am writing a feature on Apache 2 for crossnodes.com. It will cover new features, and quotes from users on why they are, or are not, upgrading from 1.3. (Besides 'if it ain't broke don't fix it') Would any of you care to address the following comment? This is from the IT director at a local ISP. Is this really an issue? "We are already using it for several sites.the biggest problem that we (and many others) have with deploying it everywhere is that the API hasn't yet stabilized, so modules, such as PHP, have to be recompiled and often slightly modified to get them to work every time Apache issues a new release. This is a pain as we often have to wait for days or weeks before all of modules that we may want to use have instructions on what to modify. "We are apprehensive about using it in shared hosting because we don't consider it release-quality software. We and many others (including the PHP development team) feel the Apache Software Foundation released it prematurely. Most notably, they continue to change core APIs on point releases, an established no-no in the open source development paradigm for supposed stable, released software." I'd like to hear from the actual developers on this! I read back several months in the list archives, to get some background. Thanks much, Carla -- ~~ Carla Schroder Bratgrrl Computing www.bratgrrl.com This message brought to you by Red Hat 8 and Kmail ~~
Re: [PATCH] Try to use OPENSSL_free instead of free
Cliff Woolley wrote: We should consider (again) setting up some kind of 'submitted patches' tracking system. Bugzilla will work fine for that. I try to attach the PatchAvailable keyword to bugs I see coming in with patches. http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-1.3&product=Apache+httpd-2.0&keywords=PatchAvailable I would encourage anyone submitting a patch to submit it first to the bug database, and then in the (likely) event you don't get a response, post here with a link to the bug and a brief description. Joshua.
Re: byterange filter/redirect bug?
[EMAIL PROTECTED] wrote: >We shouldn't be returning 416 "Invalid Range" for something that's > redirected, but it sure looks like we are. I wonder what the byterange filter > does when it sees a redirect response, and there are input Range: headers? To answer my own question, it's definately busted. I'll work up a patch for daedalus to bail out of the byterange filter if the status isn't 200 HTTP_OK upon entry, then look at the RFC and 1.3 to see if that's the right solution. Greg [gregames@gandalf netcat]$ cat redirect.no_br HEAD /dist/httpd/binaries/win32/apache_2.0.43-win32-x86-no_ssl.exe HTTP/1.1 Host: www.apache.org [gregames@gandalf netcat]$ nc www.apache.org 80 < redirect.no_br HTTP/1.1 302 Found Date: Fri, 25 Oct 2002 13:55:53 GMT Server: Apache/2.0.43 (Unix) Location: http://nagoya.apache.org/dist/httpd/binaries/win32/apache_2.0.43-win32-x86-no_ssl.exe Content-Type: text/html; charset=iso-8859-1 [gregames@gandalf netcat]$ cat redirect.br16k HEAD /dist/httpd/binaries/win32/apache_2.0.43-win32-x86-no_ssl.exe HTTP/1.1 Host: www.apache.org Range: bytes=16000- [gregames@gandalf netcat]$ nc www.apache.org 80 < redirect.br16k HTTP/1.1 416 Requested Range Not Satisfiable Date: Fri, 25 Oct 2002 13:56:23 GMT Server: Apache/2.0.43 (Unix) Content-Type: text/html; charset=iso-8859-1
RE: [PATCH] Try to use OPENSSL_free instead of free
On Thu, 24 Oct 2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > Can somebody _please_ take some time to review and tell me if the patch is > okay. Hey Madhu! I apologize on behalf of the group for letting patches slip through the cracks. It's unfortunately the case all too often that if a given developer (myself included) isn't directly working on the particular thing the patch addresses, nobody looks at it because "somebody else will do it." We should consider (again) setting up some kind of 'submitted patches' tracking system. As for your patch in particular, it looks quite fine indeed to me at first glance... I don't have time today to test and commit it but I will do so this weekend if nobody beats me to it. Thanks again, Cliff
Re: cvs commit: httpd-2.0/server request.c
Jeff Trawick wrote: > > I'm very surprised that the first % in your format string > doesn't need to be escaped. right. the missing comma was due to a stray keystroke exiting the editor. the missing '%'.. i'm not sure how that happened. fixed, anyway. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: [PROPOSAL] make child processes more awareable
At 09:56 AM 10/25/2002, Mladen Turk wrote: >And finally, the API: > >1. ap_is_one_process() >2. ap_get_parent_id() >3. ap_get_revolution() >4. ap_get_num_childs() > >Thoughts? First, to -some- degree these sorts of decisions reflect bad architecture. We -should- have provided the hooks so that no decision was necessary. They indicate places where the code will go nutty on a one-off sort of MPM. All that said, they are unavoidable questions today. However, these all belong to the MPM itself. The MPM needs to communicate where you are [a stub parent .exe that won't ever execute client requests, a real parent who's actions are inheritable, etc.] Keep your eye on the MPM design, and also consider using pool data registered against the global process pool to track if you have done some initialization once before, between generations, etc. Bill
Re: cvs commit: httpd-2.0/server request.c
[EMAIL PROTECTED] writes:
> Index: request.c
> ===
> RCS file: /home/cvs/httpd-2.0/server/request.c,v
> retrieving revision 1.115
> retrieving revision 1.116
> diff -u -u -r1.115 -r1.116
> --- request.c 5 Sep 2002 06:59:14 - 1.115
> +++ request.c 25 Oct 2002 16:27:38 - 1.116
> @@ -149,6 +149,12 @@
>if (!r->proxyreq && r->parsed_uri.path) {
>access_status = ap_unescape_url(r->parsed_uri.path);
>if (access_status) {
> +if (access_status == HTTP_NOT_FOUND) {
> +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> + "found %2f (encoded '/') in URI "
> + "(decoded='%s'), returning 404"
> + r->parsed_uri.path);
> +}
I'm very surprised that the first % in your format string doesn't
need to be escaped.
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
[PROPOSAL] make child processes more awareable
Hi, This proposal is from the module developer point of view, so it might be totally wrong from the server one. Simply I wish as a module (I'm trying to write that in a second person; and certainly in the bad English ;) to be aware of the server status. More frankly couple of things: 1. Am I been called from the one process mode. 2. If I'm called from the parent, what is its pid (there is no getppid on all platforms)? 3. Am I restarted because of my bad behavior? 4. How many processes that I'm going to be part of do you plan to launch? All that can be IMHO done in the easiest way by using command line arguments, so: 1. make one_process non static. 2. add the -p getpid() to the master_main 3. add -r revoulutions++ to the child_main 4. add -i startservers to the master_main And finally, the API: 1. ap_is_one_process() 2. ap_get_parent_id() 3. ap_get_revolution() 4. ap_get_num_childs() Thoughts? MT.
