Re: bug with flush buckets in ap_http_chunk_filter?
On Thu, Dec 15, 2005 at 11:55:30PM +0100, Ruediger Pluem wrote: > While reading the code of ap_http_chunk_filter I wondered myself if there is > bug > in the handling of flush buckets in ap_http_chunk_filter. Maybe I just do not > understand correctly the way ap_http_chunk_filter works. I think you're absolutely correct. Nice catch! Your patch looks right. Please commit to trunk. And, a +1 to merge back to 2.0 and 2.2. The fact that no one's caught this before is just weird. I bet we might be able to write up a mod_bucketeer test for this (not that I have any clue how to write it; but I'd imagine we could). -- justin
Re: [PATCH] Rename to Apache D
On Dec 15, 2005, at 1:17 PM, Justin Erenkrantz wrote: --On December 15, 2005 8:39:01 AM -0700 Brad Nicholes <[EMAIL PROTECTED]> wrote: You're not really serious about this are you? It is a little You must have missed Paul's lightning talk at AC. =) -- justin I think 90% of folks on this list did, me included. Was there interpretive dance? S. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Rename to Apache D
--On December 15, 2005 4:34:19 PM -0700 Brad Nicholes <[EMAIL PROTECTED]> wrote: No, I was there. I just assumed that it was the beer talking. I'd go with your first assumption. =) -- justin
Re: [PATCH] Rename to Apache D
> {
>
On 12/15/2005 at 2:17:45 pm, in message
> <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
> wrote:
> --On December 15, 2005 8:39:01 AM -0700 Brad Nicholes
<[EMAIL PROTECTED]> wrote:
>
> You're not really serious about this are you? It is a little
>
>You must have missed Paul's lightning talk at AC. =) -- justin
No, I was there. I just assumed that it was the beer talking.
Brad
bug with flush buckets in ap_http_chunk_filter?
While reading the code of ap_http_chunk_filter I wondered myself if there is bug
in the handling of flush buckets in ap_http_chunk_filter. Maybe I just do not
understand correctly the way ap_http_chunk_filter works.
Lets assume the following brigade as input to ap_http_chunk_filter:
Pos TypeLength
0 Heap10
1 Flush 0
2 Heap10
To be honest, I am not quite sure if this assumption can occur.
As far as I undestand we would leave the inner for loop with
bytes set to 20 and flush set to the flush bucket at pos 1 of the brigade
But the result of the "if (bytes > 0)" block would be the following brigade:
Pos TypeLength Contents
0 ImmortalLength of chunk (20 bytes) including CRLF
1 Heap10
2 ImmortalCRLF (end of chunk)
3 Flush 0
4 Heap10
But this would be wrong, as
- the length of the chunk is wrong (it is only 10)
- The 10 bytes from heap bucket 4 do not get correctly chunk encoded
If I see things correctly the following patch should fix this:
Index: chunk_filter.c
===
--- chunk_filter.c (Revision 356370)
+++ chunk_filter.c (Arbeitskopie)
@@ -69,6 +69,8 @@
}
if (APR_BUCKET_IS_FLUSH(e)) {
flush = e;
+more = apr_brigade_split(b, APR_BUCKET_NEXT(e));
+break;
}
else if (e->length == (apr_size_t)-1) {
/* unknown amount of data (e.g. a pipe) */
Regards
Rüdiger
Re: [PATCH] Rename to Apache D
--On December 15, 2005 8:39:01 AM -0700 Brad Nicholes <[EMAIL PROTECTED]> wrote: You're not really serious about this are you? It is a little You must have missed Paul's lightning talk at AC. =) -- justin
Re: AW: AW: 2.2 mod_http_proxy and "partial" pages
On 12/15/2005 09:35 PM, Brian Akins wrote: > Plüm wrote: > This would give the client the > >> impression that the response had been correct and complete (provided >> that the reponse was in chunked encoding). If the client is a proxy >> this could lead to a cache poisoning. > > > THis is why I favor closing the connection to the client. It's simple > and the client will know that something bad happen and, usually, retry. Yes, but we need to ensure that in the case of chunked encoding the client does not get the impression that everything worked well. From my perspective this can only be reached by - not sending the zero chunk - closing the connection If we send the zero chunk the client has no possibility to find out that something went wrong. I think we have to simulate to the client what happened to us on the backend: A broken connection. Regards Rüdiger
Re: AW: AW: 2.2 mod_http_proxy and "partial" pages
Plüm wrote: This would give the client the impression that the response had been correct and complete (provided that the reponse was in chunked encoding). If the client is a proxy this could lead to a cache poisoning. THis is why I favor closing the connection to the client. It's simple and the client will know that something bad happen and, usually, retry. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: How to determine if a graceful restart is initiated from within a module
Hi Colm, We have a customer who wants cgi scripts to be killed after a graceful restart after 'some' time. So I am implementing a timer that will be configurable so that after that time has elapsed cgid can terminate the child cgi processes that are still around. For that I need to know if it is a graceful restart and I am looking at ways of getting that information. Regards, Kiran Colm MacCarthaigh wrote: Apologies for the late reply, I was actually looking at this codeyesterday, and no there is no convienent way to do it, but why is thatyou want to ?It'll take some form of IPC to do this, but I'm shortly about to startwriting a complete replacement for mod_cgid which we may or may not endup using, so it'd be useful to have feedback on why you need to do thisand what additional requirements we can try and fulfill.On Thu, Nov 24, 2005 at 06:17:34PM +0530, Kiran Mendonce wrote: I wanted to add that I am working om mod_cgid and thats where I want to check if it is a graceful restart. I did some more investigation and found that listener_may_exit is not set during a graceful restart for cgid which is why ap_graceful_stop_signalled() does not return 1. Is there any way I can find if it is a graceful restart in mod_cgid ?Thanks and Regards,KiranKiran Mendonce wrote: Hi,I'd like to know how a module can determine if a graceful restart has been issued. I tried using the ap_mpm_query() and the ap_graceful_stop_signalled() APIs but I have'nt really been able to get what I want. ap_mpm_query() always returns 0 on graceful/restart/stop conditions and ap_graceful_stop_signalled() does not return 1 on graceful restart.So I'm confused what to do. Any suggestions ?Thanks and Regards,Kiran
Re: A mod_mbox release ?
Maxime Petazzoni wrote: > ... > > I'm not yet used to release management (even for a small module like > mod_mbox), so I'll be very pleased to get some feedback, comments and > pointers if we decide to make a 0.2 release for mod_mbox ! I think Sam (=Maxime) is too modest to ask for the inclusion of mod_mbox in the "modules/experimental" directory httpd; I think that this was the original purpose of giving it to SoC, wasn't it? And I'm sure that Sam will agree to promise to agree for future axing of his module, IF it will not prove the benefit and quality that are expected from a standard module of Apache. In any case, thank you Sam! -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: [PATCH] Rename to Apache D
Brad Nicholes wrote: > You're not really serious about this are you? It is a little > premature to rename something to 'd' that is still very much 'httpd'. > Get the code in place first and then see if it makes sense to worry > about trivial things like renaming the binary. While I don't have vote rights, I have an idea for a compromise that will reflect the opinions of both sides: Since Ryan Bloom wrote his mod_pop3 as a proof of concept (where the "concept" was the independence of Apache on specific protocol, though - to be more precise - it still depended on HTTPD), several other non- HTTP protocols were implemented (mod_ftpd and mod_smtpd, to name the main ones). While the Apache server does support the ability to code such modules, it neither CONTAINS them, nor IMPLEMENTS them, but only the HTTP protocol. You can't omit the "httpd" name from a server as long as all it does (ignoring 3rd party modules and external ones) is HTTP. Once these modules are integrated into the Apache server, such a rename will make a lot of sense. And I want to use this opportunity to pass a message from me and other Apache users/developers/integrators I know: PLEASE consider the integration of these modules (ftpd and smtpd) into Apache, at least for the "experimental" directory. the current status is anomal for FTP: Proxying it is supported (mod_proxy_ftp), but the original service is not. And regarding smtpd: if mod_mbox will be integrated, its combination with mod_smtpd creates an end-to-end messaging solution, which is a great thing, at least IMHO. I don't see how inclusion of non-HTTP modules in the experimental directory, with a default exclusion from builds, will break anything, especially when the claim is that the Apache server is not HTTP-centric anymore, and especially^2 when this claim is followed by considering the rename from "httpd" to "d". Thanks for taking the time to read me, -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
AW: AW: 2.2 mod_http_proxy and "partial" pages
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> Gesendet: Donnerstag, 15. Dezember 2005 17:02
> An: dev@httpd.apache.org
> Betreff: Re: AW: 2.2 mod_http_proxy and "partial" pages
>
>
{..cut..]
> >
> > Sorry, but I think I have to disagree.
> > There is nothing that can be handled anymore since the headers had
> > been sent to the client.
> > The only part of the chain that handles error buckets so
> far is the
> > http header filter which is gone at
> > this point of time.
>
> IMO, that's the problem... The core output filter should be
> aware of this error. Not sure if "magically" noticing this
> when removing empty buckets is the right solution...
>
No problem. Let's discuss where to place this. I just placed it
into the remove_empty_buckets function as I wanted to avoid to run
a loop twice over the brigade. I think I need some kind of loop
because otherwise I might miss this bucket (e.g. in remove_empty_bucket,
if there are other meta buckets before the error bucket).
Having the check only in writev_nonblocking might lead to a miss of
this bucket.
Anyway I detected another problem that is also there with my current
patch proposal. I think we need to make the ap_http_chunk_filter aware of this
error bucket. Otherwise it will add the "closing" zero length chunk to
the response once it sees the eos bucket. This would give the client the
impression that the response had been correct and complete (provided
that the reponse was in chunked encoding). If the client is a proxy
this could lead to a cache poisoning. So my proposal is that we do
*not* insert the "closing" zero length chunk to signal the client
that the response is not complete and broke in the middle.
Regards
Rüdiger
Re: Apache 2.2 third party module support issue.
On Dec 14, 2005, at 1:57 AM, Mukesh_Kumar02 wrote: Is the same library supported on Apache 2.2? Do I need to change/reconfigure/recompile the same for Apache 2.2? If so kindly guide me through the process. Because of changes within the API between 2.0 and 2.2, 2.0 modules will not work with 2.2. The vast majority just need to be recompiled (no real porting), via apxs. The httpd docs tell how.
Re: AW: 2.2 mod_http_proxy and "partial" pages
On Dec 13, 2005, at 7:32 PM, Ruediger Pluem wrote: On 12/14/2005 12:59 AM, Jim Jagielski wrote: On Dec 13, 2005, at 1:28 PM, Ruediger Pluem wrote: [..cut..] The reason the other patch didn't do this is that, upon reflection, closing the client connection at this point does not seem quite right. Closing it simply because the gateway died just doesn't feel right, and seems almost overkill. I think simply setting the error bucket to allow the rest of the chain to correctly handle it, is the best we could (and should) do :/ Sorry, but I think I have to disagree. There is nothing that can be handled anymore since the headers had been sent to the client. The only part of the chain that handles error buckets so far is the http header filter which is gone at this point of time. IMO, that's the problem... The core output filter should be aware of this error. Not sure if "magically" noticing this when removing empty buckets is the right solution...
Re: [PATCH] Rename to Apache D
Maybe just a touch premature? :) On Dec 14, 2005, at 3:21 PM, Paul Querna wrote: The attached patch is just a start, fixing the configure.in to generate the correct binary name by default. -Paul Index: configure.in === --- configure.in(revision 355792) +++ configure.in(working copy) @@ -527,7 +527,7 @@ AC_ARG_WITH(program-name, APACHE_HELP_STRING(--with-program-name,alternate executable name),[ progname="$withval" ], [ - progname="httpd"] ) + progname="d"] ) # SuExec parameters AC_ARG_WITH(suexec-bin,
AW: [PATCH] Rename to Apache D
> -Ursprüngliche Nachricht- > Von: Brad Nicholes > Gesendet: Donnerstag, 15. Dezember 2005 16:39 > An: > Betreff: Re: [PATCH] Rename to Apache D > > > > You're not really serious about this are you? It is a > little premature to rename something to 'd' that is still > very much 'httpd'. > Get the code in place first and then see if it makes sense to > worry about trivial things like renaming the binary. +1 Regards Rüdiger [..cut..]
Re: [PATCH] Rename to Apache D
You're not really serious about this are you? It is a little premature to rename something to 'd' that is still very much 'httpd'. Get the code in place first and then see if it makes sense to worry about trivial things like renaming the binary. Brad >>> On 12/14/2005 at 1:21:20 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > The attached patch is just a start, fixing the configure.in to generate > the correct binary name by default. > > -Paul
Re: Apache 2.2.0 for Windows
Or you could just build the released unix source on windows.ALthough you need to do some tweaking to be able to do it.~Jorge
