Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml
Would it be possible to skip the SVN commit diff email? Like it is possible with [skip ci] to bypass the CI runs. On Wed, Aug 19, 2020 at 7:35 AM Joe Orton wrote: > On Wed, Aug 19, 2020 at 10:08:12AM +0200, Christophe JAILLET wrote: > > Le 19/08/2020 à 09:47, Joe Orton a écrit : > > > Stupid question, why do we need to change the suffix to .utf8 to > convert > > > these files into UTF-8? > > > > I don't think it is needed, just a matter of consistancy in naming. > > See r1878788 to see the magic needed to concert to UTF-8 (without > renaming > > files) > > [Adding docs@ to CC.] > > Shall we move everything (except for Korean?) to UTF-8 and drop the > .utf8 suffix as well? It would still be consistent then. > > (I only just renamed those files but, revisions are cheap? ;) > > Only problem is the 100-part SVN commit diff e-mail? > > Regards, Joe > >
Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml
On Wed, Aug 19, 2020 at 10:08:12AM +0200, Christophe JAILLET wrote: > Le 19/08/2020 à 09:47, Joe Orton a écrit : > > Stupid question, why do we need to change the suffix to .utf8 to convert > > these files into UTF-8? > > I don't think it is needed, just a matter of consistancy in naming. > See r1878788 to see the magic needed to concert to UTF-8 (without renaming > files) [Adding docs@ to CC.] Shall we move everything (except for Korean?) to UTF-8 and drop the .utf8 suffix as well? It would still be consistent then. (I only just renamed those files but, revisions are cheap? ;) Only problem is the 100-part SVN commit diff e-mail? Regards, Joe
Re: mod_http2 behavior in case of too many or too large request headers
> Am 19.08.2020 um 12:08 schrieb Ruediger Pluem : > > If mod_http2 detects too many or too large request headers in > h2_stream_add_header or h2_stream_end_headers it does not create a > pseudo HTTP/1.1 request but directly responds back on the HTTP/2 stream. > While this is very efficient from the HTTP/2 perspective > it has some bad drawbacks from my perspective: > > 1. The request is not logged in the access log. > 2. Possible custom ErrorDocuments for this status code > (HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE, 431) are ignored. The main reasons (as far as my memory serves) are: - that at that time, the whole h1 infrastructure has not been set up yet. - reporting on requests and error doc handling is only possible from h1 - it seems counter-intuitive to construct and schedule a h1 request for something that is not valid input > I would like to see this changed to have the drawbacks above addressed. > Thoughts? Ceterum censeo: to make all features currently tied to h1 work for other protocol, one needs to separate them into a "http" layer that is agnostic to the serialization of requests/responses. As another example, see: https://github.com/icing/mod_h2/issues/203 > One approach I thought about is that set_error_response would set the > http_status in a not yet existing field (e.g. early_status) > of the h2_request struct via stream->rtmp instead of creating a brigade in > stream->out_buffer and adding to it. > h2_request_create_rec could then check for this field and if non zero call > ap_die after doing some minimal request_rec setup. > I could hack something up for more detailed discussion if this approach seems > acceptable. > > BTW: Is the check for the field length in h2_stream_end_headers still needed > as I think that h2_req_add_header called via > h2_request_add_header by h2_stream_add_header already takes care of it? Can't say without a closer look which I atm lack the time. - Stefan > > Regards > > Rüdiger
mod_http2 behavior in case of too many or too large request headers
If mod_http2 detects too many or too large request headers in h2_stream_add_header or h2_stream_end_headers it does not create a pseudo HTTP/1.1 request but directly responds back on the HTTP/2 stream. While this is very efficient from the HTTP/2 perspective it has some bad drawbacks from my perspective: 1. The request is not logged in the access log. 2. Possible custom ErrorDocuments for this status code (HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE, 431) are ignored. I would like to see this changed to have the drawbacks above addressed. Thoughts? One approach I thought about is that set_error_response would set the http_status in a not yet existing field (e.g. early_status) of the h2_request struct via stream->rtmp instead of creating a brigade in stream->out_buffer and adding to it. h2_request_create_rec could then check for this field and if non zero call ap_die after doing some minimal request_rec setup. I could hack something up for more detailed discussion if this approach seems acceptable. BTW: Is the check for the field length in h2_stream_end_headers still needed as I think that h2_req_add_header called via h2_request_add_header by h2_stream_add_header already takes care of it? Regards Rüdiger
Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml
Le 19/08/2020 à 09:47, Joe Orton a écrit : On Wed, Aug 19, 2020 at 08:36:02AM +0100, Joe Orton wrote: On Tue, Aug 18, 2020 at 07:08:21AM -0400, Eric Covener wrote: On Tue, Aug 18, 2020 at 6:34 AM Joe Orton wrote: On Tue, Jul 28, 2020 at 07:32:01AM -0400, Eric Covener wrote: FYI I am seeing if I can coordinate with Humbedooh to change all the generated files without one of those 17-part commit threads. But I will probably just commit in the next few hours either way. Does this still need to be done for trunk? I'm kind of lost here (as usual with the docs), but running "./build.sh all" in trunk gives me a tonne of *.html.en.utf8 files. I have docs/manual/build at r1880369 Should we do a mass "svn mv" for .html.en to .html.en.utf8? yes sorry. It looks nearly as noisy in the commit when I tested it but I did chat with Daniel and he said just bite the bullet and don't fiddle around with the mailing list. Thanks & no worries. The public /docs/trunk/ content still seems to be working so I'm hoping I haven't completely broken everything: r1880980 - magic bootstrap step needed to regenerate the typemaps correctly r1880982 - surely the longest I have ever seen svn commit run for ... in fact in r1880982 I only ran "./build.sh en" I think. And I am still seeing a big diff changing ISO-8859-1 characters into HTML entities for other languages when re-running "build.sh all": $ svn diff vhosts/index.html.de | head Index: vhosts/index.html.de === --- vhosts/index.html.de(revision 1880979) +++ vhosts/index.html.de(working copy) @@ -23,59 +23,59 @@ http://www.apache.org/;>Apache http://httpd.apache.org/;>HTTP-Server http://httpd.apache.org/docs/;>Dokumentation Version 2.5Apache-Dokumentation zu virtuellen Hosts -Verf�gbare Sprachen: de | +Verfgbare Sprachen: de | FWIW, using: $ $JAVA_HOME/bin/java -version openjdk version "11.0.8" 2020-07-14 OpenJDK Runtime Environment 18.9 (build 11.0.8+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.8+10, mixed mode, sharing) Stupid question, why do we need to change the suffix to .utf8 to convert these files into UTF-8? I don't think it is needed, just a matter of consistancy in naming. See r1878788 to see the magic needed to concert to UTF-8 (without renaming files) CJ M man/htdbm.1 M manual/bind.html.de M manual/configuring.html.de M manual/glossary.html.de M manual/howto/htaccess.html.pt-br M manual/index.html.da M manual/index.html.de M manual/index.html.pt-br M manual/install.html.de M manual/invoking.html.de M manual/mod/core.html.de M manual/mod/core.html.es.utf8 M manual/mod/core.html.ja.utf8 M manual/mod/core.html.tr.utf8 M manual/mod/directives.html.de M manual/mod/directives.html.ja.utf8 M manual/mod/directives.html.ko.euc-kr M manual/mod/directives.html.tr.utf8 M manual/mod/directives.html.zh-cn.utf8 M manual/mod/index.html.de M manual/mod/mod_actions.html.de M manual/mod/mpm_common.html.de M manual/mod/mpm_winnt.html.de M manual/mod/prefork.html.de M manual/mod/quickreference.html.de M manual/mod/quickreference.html.ja.utf8 M manual/mod/quickreference.html.ko.euc-kr M manual/mod/quickreference.html.tr.utf8 M manual/mod/quickreference.html.zh-cn.utf8 M manual/mod/worker.html.de M manual/mpm.html.de M manual/new_features_2_0.html.de M manual/new_features_2_0.html.pt-br M manual/new_features_2_2.html.pt-br M manual/sitemap.html.de M manual/stopping.html.de M manual/vhosts/index.html.de M manual/vhosts/name-based.html.de
Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml
Le 19/08/2020 à 09:57, Ruediger Pluem a écrit : On 8/19/20 9:47 AM, Joe Orton wrote: On Wed, Aug 19, 2020 at 08:36:02AM +0100, Joe Orton wrote: On Tue, Aug 18, 2020 at 07:08:21AM -0400, Eric Covener wrote: On Tue, Aug 18, 2020 at 6:34 AM Joe Orton wrote: On Tue, Jul 28, 2020 at 07:32:01AM -0400, Eric Covener wrote: FYI I am seeing if I can coordinate with Humbedooh to change all the generated files without one of those 17-part commit threads. But I will probably just commit in the next few hours either way. Does this still need to be done for trunk? I'm kind of lost here (as usual with the docs), but running "./build.sh all" in trunk gives me a tonne of *.html.en.utf8 files. I have docs/manual/build at r1880369 Should we do a mass "svn mv" for .html.en to .html.en.utf8? yes sorry. It looks nearly as noisy in the commit when I tested it but I did chat with Daniel and he said just bite the bullet and don't fiddle around with the mailing list. Thanks & no worries. The public /docs/trunk/ content still seems to be working so I'm hoping I haven't completely broken everything: r1880980 - magic bootstrap step needed to regenerate the typemaps correctly r1880982 - surely the longest I have ever seen svn commit run for ... in fact in r1880982 I only ran "./build.sh en" I think. And I am still seeing a big diff changing ISO-8859-1 characters into HTML entities for other languages when re-running "build.sh all": Should we move these languages to utf8 as well like we did for en? Regards Rüdiger +1
Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml
On 8/19/20 9:47 AM, Joe Orton wrote: > On Wed, Aug 19, 2020 at 08:36:02AM +0100, Joe Orton wrote: >> On Tue, Aug 18, 2020 at 07:08:21AM -0400, Eric Covener wrote: >>> On Tue, Aug 18, 2020 at 6:34 AM Joe Orton wrote: On Tue, Jul 28, 2020 at 07:32:01AM -0400, Eric Covener wrote: > FYI I am seeing if I can coordinate with Humbedooh to change all the > generated files without one of those 17-part commit threads. > But I will probably just commit in the next few hours either way. Does this still need to be done for trunk? I'm kind of lost here (as usual with the docs), but running "./build.sh all" in trunk gives me a tonne of *.html.en.utf8 files. I have docs/manual/build at r1880369 Should we do a mass "svn mv" for .html.en to .html.en.utf8? >>> >>> yes sorry. It looks nearly as noisy in the commit when I tested it but >>> I did chat with Daniel and he said just bite the bullet and don't >>> fiddle around with the mailing list. >> >> Thanks & no worries. The public /docs/trunk/ content still seems to be >> working so I'm hoping I haven't completely broken everything: >> >> r1880980 - magic bootstrap step needed to regenerate the typemaps correctly >> r1880982 - surely the longest I have ever seen svn commit run for > > ... in fact in r1880982 I only ran "./build.sh en" I think. > > And I am still seeing a big diff changing ISO-8859-1 characters into > HTML entities for other languages when re-running "build.sh all": Should we move these languages to utf8 as well like we did for en? Regards Rüdiger
Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml
On Wed, Aug 19, 2020 at 08:36:02AM +0100, Joe Orton wrote: > On Tue, Aug 18, 2020 at 07:08:21AM -0400, Eric Covener wrote: > > On Tue, Aug 18, 2020 at 6:34 AM Joe Orton wrote: > > > > > > On Tue, Jul 28, 2020 at 07:32:01AM -0400, Eric Covener wrote: > > > > FYI I am seeing if I can coordinate with Humbedooh to change all the > > > > generated files without one of those 17-part commit threads. > > > > But I will probably just commit in the next few hours either way. > > > > > > Does this still need to be done for trunk? I'm kind of lost here (as > > > usual with the docs), but running "./build.sh all" in trunk gives me a > > > tonne of *.html.en.utf8 files. > > > > > > I have docs/manual/build at r1880369 > > > > > > Should we do a mass "svn mv" for .html.en to .html.en.utf8? > > > > yes sorry. It looks nearly as noisy in the commit when I tested it but > > I did chat with Daniel and he said just bite the bullet and don't > > fiddle around with the mailing list. > > Thanks & no worries. The public /docs/trunk/ content still seems to be > working so I'm hoping I haven't completely broken everything: > > r1880980 - magic bootstrap step needed to regenerate the typemaps correctly > r1880982 - surely the longest I have ever seen svn commit run for ... in fact in r1880982 I only ran "./build.sh en" I think. And I am still seeing a big diff changing ISO-8859-1 characters into HTML entities for other languages when re-running "build.sh all": $ svn diff vhosts/index.html.de | head Index: vhosts/index.html.de === --- vhosts/index.html.de(revision 1880979) +++ vhosts/index.html.de(working copy) @@ -23,59 +23,59 @@ http://www.apache.org/;>Apache http://httpd.apache.org/;>HTTP-Server http://httpd.apache.org/docs/;>Dokumentation Version 2.5Apache-Dokumentation zu virtuellen Hosts -Verf�gbare Sprachen: de | +Verfgbare Sprachen: de | FWIW, using: $ $JAVA_HOME/bin/java -version openjdk version "11.0.8" 2020-07-14 OpenJDK Runtime Environment 18.9 (build 11.0.8+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.8+10, mixed mode, sharing) Stupid question, why do we need to change the suffix to .utf8 to convert these files into UTF-8? M man/htdbm.1 M manual/bind.html.de M manual/configuring.html.de M manual/glossary.html.de M manual/howto/htaccess.html.pt-br M manual/index.html.da M manual/index.html.de M manual/index.html.pt-br M manual/install.html.de M manual/invoking.html.de M manual/mod/core.html.de M manual/mod/core.html.es.utf8 M manual/mod/core.html.ja.utf8 M manual/mod/core.html.tr.utf8 M manual/mod/directives.html.de M manual/mod/directives.html.ja.utf8 M manual/mod/directives.html.ko.euc-kr M manual/mod/directives.html.tr.utf8 M manual/mod/directives.html.zh-cn.utf8 M manual/mod/index.html.de M manual/mod/mod_actions.html.de M manual/mod/mpm_common.html.de M manual/mod/mpm_winnt.html.de M manual/mod/prefork.html.de M manual/mod/quickreference.html.de M manual/mod/quickreference.html.ja.utf8 M manual/mod/quickreference.html.ko.euc-kr M manual/mod/quickreference.html.tr.utf8 M manual/mod/quickreference.html.zh-cn.utf8 M manual/mod/worker.html.de M manual/mpm.html.de M manual/new_features_2_0.html.de M manual/new_features_2_0.html.pt-br M manual/new_features_2_2.html.pt-br M manual/sitemap.html.de M manual/stopping.html.de M manual/vhosts/index.html.de M manual/vhosts/name-based.html.de
Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml
On Tue, Aug 18, 2020 at 07:08:21AM -0400, Eric Covener wrote: > On Tue, Aug 18, 2020 at 6:34 AM Joe Orton wrote: > > > > On Tue, Jul 28, 2020 at 07:32:01AM -0400, Eric Covener wrote: > > > FYI I am seeing if I can coordinate with Humbedooh to change all the > > > generated files without one of those 17-part commit threads. > > > But I will probably just commit in the next few hours either way. > > > > Does this still need to be done for trunk? I'm kind of lost here (as > > usual with the docs), but running "./build.sh all" in trunk gives me a > > tonne of *.html.en.utf8 files. > > > > I have docs/manual/build at r1880369 > > > > Should we do a mass "svn mv" for .html.en to .html.en.utf8? > > yes sorry. It looks nearly as noisy in the commit when I tested it but > I did chat with Daniel and he said just bite the bullet and don't > fiddle around with the mailing list. Thanks & no worries. The public /docs/trunk/ content still seems to be working so I'm hoping I haven't completely broken everything: r1880980 - magic bootstrap step needed to regenerate the typemaps correctly r1880982 - surely the longest I have ever seen svn commit run for
