Re: HTTP and HTTP/1.x separation
On 28/03/2022 16:03, Stefan Eissing wrote: Am 28.03.2022 um 15:52 schrieb jean-frederic clere : On 24/03/2022 13:21, Stefan Eissing wrote: You are invited to have a look at my PR for separating HTTP/1.x processing from generic HTTP protocol handling and verification: https://github.com/apache/httpd/pull/291 I made a description of the changes in the PR that helps reviewing it (I hope). "Changes appear larger than they really are" A lot is code split+move from mod_http to mod_http1. In mod_http2, changes are mainly removals of quirks necessary so far. Kind Regards, Stefan Something fishy: http/1.1: +++ < HTTP/1.1 200 OK < Date: Mon, 28 Mar 2022 13:48:23 GMT < Server: Apache/2.5.1-dev (Unix) OpenSSL/1.1.1n < Last-Modified: Fri, 25 Mar 2022 15:47:39 GMT < ETag: "bf-5db0ce1e1e93e" < Accept-Ranges: bytes < Content-Length: 191 < Content-Type: text/html +++ http/2: +++ < HTTP/2 200 < last-modified: Fri, 25 Mar 2022 15:47:39 GMT < etag: "bf-5db0ce1e1e93e" < accept-ranges: bytes < content-length: 191 < content-type: text/html +++ Did I miss something? No, you found something. The generic server headers are not applied, it seems. Will look into this and add a test. -- Cheers Jean-Frederic I think we have NO http/2 tests in the httpd-framework test, correct? -- Cheers Jean-Frederic
Re: HTTP and HTTP/1.x separation
> Am 28.03.2022 um 17:15 schrieb jean-frederic clere : > > On 28/03/2022 16:03, Stefan Eissing wrote: >>> Am 28.03.2022 um 15:52 schrieb jean-frederic clere : >>> >>> On 24/03/2022 13:21, Stefan Eissing wrote: You are invited to have a look at my PR for separating HTTP/1.x processing from generic HTTP protocol handling and verification: https://github.com/apache/httpd/pull/291 I made a description of the changes in the PR that helps reviewing it (I hope). "Changes appear larger than they really are" A lot is code split+move from mod_http to mod_http1. In mod_http2, changes are mainly removals of quirks necessary so far. Kind Regards, Stefan >>> >>> Something fishy: >>> http/1.1: >>> +++ >>> >>> < HTTP/1.1 200 OK >>> < Date: Mon, 28 Mar 2022 13:48:23 GMT >>> < Server: Apache/2.5.1-dev (Unix) OpenSSL/1.1.1n >>> < Last-Modified: Fri, 25 Mar 2022 15:47:39 GMT >>> < ETag: "bf-5db0ce1e1e93e" >>> < Accept-Ranges: bytes >>> < Content-Length: 191 >>> < Content-Type: text/html >>> >>> +++ >>> http/2: >>> +++ >>> < HTTP/2 200 >>> < last-modified: Fri, 25 Mar 2022 15:47:39 GMT >>> < etag: "bf-5db0ce1e1e93e" >>> < accept-ranges: bytes >>> < content-length: 191 >>> < content-type: text/html >>> +++ >>> >>> Did I miss something? >> No, you found something. The generic server headers are not applied, it >> seems. Will look into this and add a test. >>> -- >>> Cheers >>> >>> Jean-Frederic >>> > > I think we have NO http/2 tests in the httpd-framework test, correct? Correct. When I first tried, the perl http2 framework was not very mature and I turned to what ultimately became the pytest suite. > > -- > Cheers > > Jean-Frederic >
Re: Support JSON output in mod_status and mod_info
On 28/03/2022 14:28, Rainer Jung wrote: I am thinking about adding a JSON output format to mod_status and mod_info as an option controlled by a query string parameter. Since writing simple data structures from these modules is much simpler than parsing and processing a JSON structure, I would expect it to be based on simple ap_rputs() and ap_rprintf() like we already use it for auto (text) and HTML output. IMHO no need for a JSON library just for this use case. Of course, this will slightly bloat the code with "if" statements and roughly double the amount of ap_rputs() and ap_rprintf(). For mod_status this probably means introduction of a new AP_STATUS_JSON value, so that in theory other modules could in the future update their status extensions with JSON support. In the meantime it might mean, that if a modules extends mod_status output, the result when asking for JSON output is no valid JSON (mix between mod_status JSON and mod_something providing HTML or text). For our own modules, especially mod_proxy, this can of course be fixed (and I will fix this). For mod_info, we do not have such an extension problem wrt. 3rd-party modules. Any comments up-front before I try to prototype this? +1 ;-) Thanks and regards, Rainer -- Cheers Jean-Frederic
Re: HTTP and HTTP/1.x separation
> Am 28.03.2022 um 15:52 schrieb jean-frederic clere : > > On 24/03/2022 13:21, Stefan Eissing wrote: >> You are invited to have a look at my PR for separating HTTP/1.x processing >> from >> generic HTTP protocol handling and verification: >> https://github.com/apache/httpd/pull/291 >> I made a description of the changes in the PR that helps reviewing it (I >> hope). >> "Changes appear larger than they really are" >> A lot is code split+move from mod_http to mod_http1. In mod_http2, changes >> are >> mainly removals of quirks necessary so far. >> Kind Regards, >> Stefan > > Something fishy: > http/1.1: > +++ > > < HTTP/1.1 200 OK > < Date: Mon, 28 Mar 2022 13:48:23 GMT > < Server: Apache/2.5.1-dev (Unix) OpenSSL/1.1.1n > < Last-Modified: Fri, 25 Mar 2022 15:47:39 GMT > < ETag: "bf-5db0ce1e1e93e" > < Accept-Ranges: bytes > < Content-Length: 191 > < Content-Type: text/html > > +++ > http/2: > +++ > < HTTP/2 200 > < last-modified: Fri, 25 Mar 2022 15:47:39 GMT > < etag: "bf-5db0ce1e1e93e" > < accept-ranges: bytes > < content-length: 191 > < content-type: text/html > +++ > > Did I miss something? No, you found something. The generic server headers are not applied, it seems. Will look into this and add a test. > -- > Cheers > > Jean-Frederic >
Re: HTTP and HTTP/1.x separation
On 24/03/2022 13:21, Stefan Eissing wrote: You are invited to have a look at my PR for separating HTTP/1.x processing from generic HTTP protocol handling and verification: https://github.com/apache/httpd/pull/291 I made a description of the changes in the PR that helps reviewing it (I hope). "Changes appear larger than they really are" A lot is code split+move from mod_http to mod_http1. In mod_http2, changes are mainly removals of quirks necessary so far. Kind Regards, Stefan Something fishy: http/1.1: +++ < HTTP/1.1 200 OK < Date: Mon, 28 Mar 2022 13:48:23 GMT < Server: Apache/2.5.1-dev (Unix) OpenSSL/1.1.1n < Last-Modified: Fri, 25 Mar 2022 15:47:39 GMT < ETag: "bf-5db0ce1e1e93e" < Accept-Ranges: bytes < Content-Length: 191 < Content-Type: text/html +++ http/2: +++ < HTTP/2 200 < last-modified: Fri, 25 Mar 2022 15:47:39 GMT < etag: "bf-5db0ce1e1e93e" < accept-ranges: bytes < content-length: 191 < content-type: text/html +++ Did I miss something? -- Cheers Jean-Frederic
Re: HTTP and HTTP/1.x separation
On 28/03/2022 17:25, Stefan Eissing wrote: Correct. When I first tried, the perl http2 framework was not very mature Yep the perl http2 module looks abandoned :-( -- Cheers Jean-Frederic
Re: httpd-framework problem.
On 28/03/2022 12:00, jean-frederic clere wrote: Hi, I have the following message with the framework: +++ t/modules/proxy_websockets.t lib/Math/Random/ISAAC/XS.c: loadable library and perl binaries are mismatched (got handshake key 0xed00080, needed 0xeb00080) t/modules/proxy_websockets.t Dubious, test returned 1 (wstat 256, 0x100) +++ Anyone one has an idea? If no I will look in details later today ;-) forget it... my bad rm -rf ~/perl5 and reinstall fixes it. -- Cheers Jean-Frederic
Support JSON output in mod_status and mod_info
I am thinking about adding a JSON output format to mod_status and mod_info as an option controlled by a query string parameter. Since writing simple data structures from these modules is much simpler than parsing and processing a JSON structure, I would expect it to be based on simple ap_rputs() and ap_rprintf() like we already use it for auto (text) and HTML output. IMHO no need for a JSON library just for this use case. Of course, this will slightly bloat the code with "if" statements and roughly double the amount of ap_rputs() and ap_rprintf(). For mod_status this probably means introduction of a new AP_STATUS_JSON value, so that in theory other modules could in the future update their status extensions with JSON support. In the meantime it might mean, that if a modules extends mod_status output, the result when asking for JSON output is no valid JSON (mix between mod_status JSON and mod_something providing HTML or text). For our own modules, especially mod_proxy, this can of course be fixed (and I will fix this). For mod_info, we do not have such an extension problem wrt. 3rd-party modules. Any comments up-front before I try to prototype this? Thanks and regards, Rainer
Re: Support JSON output in mod_status and mod_info
> Am 28.03.2022 um 14:28 schrieb Rainer Jung : > > > I am thinking about adding a JSON output format to mod_status and mod_info as > an option controlled by a query string parameter. > > Since writing simple data structures from these modules is much simpler than > parsing and processing a JSON structure, I would expect it to be based on > simple ap_rputs() and ap_rprintf() like we already use it for auto (text) and > HTML output. IMHO no need for a JSON library just for this use case. > > Of course, this will slightly bloat the code with "if" statements and roughly > double the amount of ap_rputs() and ap_rprintf(). > > For mod_status this probably means introduction of a new AP_STATUS_JSON > value, so that in theory other modules could in the future update their > status extensions with JSON support. In the meantime it might mean, that if a > modules extends mod_status output, the result when asking for JSON output is > no valid JSON (mix between mod_status JSON and mod_something providing HTML > or text). For our own modules, especially mod_proxy, this can of course be > fixed (and I will fix this). For mod_info, we do not have such an extension > problem wrt. 3rd-party modules. > > Any comments up-front before I try to prototype this? +1 (a big one) Suggestion: we could add an additional `status_hook` like `status_json_hook` so that existing one do not get confused? Kind Regards, Stefan > > Thanks and regards, > > Rainer
httpd-framework problem.
Hi, I have the following message with the framework: +++ t/modules/proxy_websockets.t lib/Math/Random/ISAAC/XS.c: loadable library and perl binaries are mismatched (got handshake key 0xed00080, needed 0xeb00080) t/modules/proxy_websockets.t Dubious, test returned 1 (wstat 256, 0x100) +++ Anyone one has an idea? If no I will look in details later today ;-) -- Cheers Jean-Frederic
