Re: migration of the HTTPD project website
On Wed, Jun 30, 2021 at 1:50 AM Ruediger Pluem wrote:
>...
> I guess he talks about
>
> # Get the tooling
> svn co https://svn.apache.org/repos/asf/httpd/site/trunk/tools tools
>
> I think we should find a new location for this as this is not really site
> related.
> How about
>
> https://svn.apache.org/repos/asf/httpd/dev-tools/trunk
>
> (svn mv https://svn.apache.org/repos/asf/httpd/site/trunk/tools
> https://svn.apache.org/repos/asf/httpd/dev-tools/trunk)
>
If we don't intend to make *releases* of these tools, then I recommend
dropping "trunk", and just call it .../httpd/dev-tools/
IMO, trunk/tags/branches ("TTB") should only be used in relation to
artifacts that will be packaged/released by the Foundation.
Cheers,
-g
Re: backend connections life times
On Wed, Jun 30, 2021 at 11:46 AM Stefan Eissing wrote: > > It looks like we stumbled upon an issue in > https://bz.apache.org/bugzilla/show_bug.cgi?id=65402 which concerns the life > times of our backend connections. > > When a frontend connection causes a backend request and drops, our backend > connection only notifies the loss when it attempts to pass some data. In > normal http response processing, this is not an issue since response chunks > are usually coming in quite frequently. Then the proxied connection will fail > to pass it to an aborted frontend connection and cleanup will occur. > > However, with such modern shenanigans such as Server Side Events (SSE), the > request is supposed to be long running and will produce body chunks quite > infrequently, like every 30 seconds or so. This leaves our proxy workers > hanging in recv for quite a while and may lead to worker exhaustion. > > We can say SSE is a bad idea anyway, but that will probably not stop people > from doing such crazy things. > > What other mitigations do we have? > - pthread_kill() will interrupt the recv and probably make it fail > - we can use shorter socket timeouts on backend and check r->connection > status in between > - ??? In trunk the tunnelling side of mod_proxy_http can go async and get called back for activity on either side by asking Event to watch both sockets. I'm not sure how browsers treat the SSE connection, can it ever have a subsequent request? If not, maybe we could see the SSE Content-Type and shoehorn it into the tunneling (figuring out what to do with writes from the client, backport the event and async tunnel stuff?)
backend connections life times
It looks like we stumbled upon an issue in https://bz.apache.org/bugzilla/show_bug.cgi?id=65402 which concerns the life times of our backend connections. When a frontend connection causes a backend request and drops, our backend connection only notifies the loss when it attempts to pass some data. In normal http response processing, this is not an issue since response chunks are usually coming in quite frequently. Then the proxied connection will fail to pass it to an aborted frontend connection and cleanup will occur. However, with such modern shenanigans such as Server Side Events (SSE), the request is supposed to be long running and will produce body chunks quite infrequently, like every 30 seconds or so. This leaves our proxy workers hanging in recv for quite a while and may lead to worker exhaustion. We can say SSE is a bad idea anyway, but that will probably not stop people from doing such crazy things. What other mitigations do we have? - pthread_kill() will interrupt the recv and probably make it fail - we can use shorter socket timeouts on backend and check r->connection status in between - ??? Whatever the means, I think it would be a Good Thing to abort backend connections earlier than we do now. WDYT? - Stefan
Re: migration of the HTTPD project website
Sent from my iPhone > On Jun 29, 2021, at 11:50 PM, Ruediger Pluem wrote: > > > >> On 6/29/21 11:23 PM, Dave Fisher wrote: >> Hi - >> On Jun 29, 2021, at 1:17 PM, Marion & Christophe JAILLET wrote: >>> > >>> >>> - some extra spaces in a command (around the use of awk) >>> (https://httpd.staged.apache.org/dev/release.html#how-to-do-a-release) >> >> Removed. BTW - this page and associated scripts need to be edited to reflect >> the website being git based. >> > > I guess he talks about > > # Get the tooling > svn co https://svn.apache.org/repos/asf/httpd/site/trunk/tools tools > > I think we should find a new location for this as this is not really site > related. > How about > > https://svn.apache.org/repos/asf/httpd/dev-tools/trunk > > (svn mv https://svn.apache.org/repos/asf/httpd/site/trunk/tools > https://svn.apache.org/repos/asf/httpd/dev-tools/trunk) > That’s the first part. Then scripts like announce.sh need to be modified. Regards, Dave > Regards > > Rüdiger
Re: svn commit: r1891148 - in /httpd/httpd/trunk: include/ap_mmn.h include/util_filter.h modules/proxy/proxy_util.c server/util_filter.c
On Tue, Jun 29, 2021 at 09:16:21PM -, yla...@apache.org wrote: > Author: ylavic > Date: Tue Jun 29 21:16:21 2021 > New Revision: 1891148 > > URL: http://svn.apache.org/viewvc?rev=1891148=rev > Log: > core: Write Completion (WC) bucket type. > > A WC bucket is meant to prevent buffering/coalescing filters from retaining > data, but unlike a FLUSH bucket it won't cause the core output filter to > block trying to flush anything before. Interesting. I think it would be helpful to have the semantics of this bucket type described in the header as well. So filters should treat a WC bucket the same as FLUSH in general? And specifically, filters are broken if they don't? It seems like an accident that this makes mod_ssl's coalesce filter flush, merely because it will flush for *any* metadata bucket type, but it didn't have to be designed that way. If so I wonder if it wouldn't be better to overload FLUSH for this, e.g. by having a FLUSH bucket with a non-NULL ->data pointer or something? The core knows it is special but everywhere else treats as FLUSH. (Seems we need bucket subclasses...) Regards, Joe
Re: migration of the HTTPD project website
On 6/29/21 11:23 PM, Dave Fisher wrote: > Hi - > >> On Jun 29, 2021, at 1:17 PM, Marion & Christophe JAILLET >> wrote: >> >> >>- some extra spaces in a command (around the use of awk) >> (https://httpd.staged.apache.org/dev/release.html#how-to-do-a-release) > > Removed. BTW - this page and associated scripts need to be edited to reflect > the website being git based. > I guess he talks about # Get the tooling svn co https://svn.apache.org/repos/asf/httpd/site/trunk/tools tools I think we should find a new location for this as this is not really site related. How about https://svn.apache.org/repos/asf/httpd/dev-tools/trunk (svn mv https://svn.apache.org/repos/asf/httpd/site/trunk/tools https://svn.apache.org/repos/asf/httpd/dev-tools/trunk) Regards Rüdiger
