[Bug 68995] New: Apache compile goes through but httpd -V throws error
https://bz.apache.org/bugzilla/show_bug.cgi?id=68995 Bug ID: 68995 Summary: Apache compile goes through but httpd -V throws error Product: Apache httpd-2 Version: 2.4.59 Hardware: PC OS: AIX Status: NEW Severity: normal Priority: P2 Component: All Assignee: bugs@httpd.apache.org Reporter: sakamurivand...@gmail.com Target Milestone: --- Compiling Apache 2.4.59 from source with apr-1.7.4, apr-util-1.6.3 and expat 2.6.2 on AIX 7.1 and the configure/make/make install all work fine. But once done, if I run #./httpd -V, I see errors as below # ./httpd -V exec(): 0509-036 Cannot load program ./httpd because of the following errors: rtld: 0712-001 Symbol XML_StopParser was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol XML_ParserCreate was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol XML_SetUserData was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol XML_SetElementHandler was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol XML_SetCharacterDataHandler was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol XML_SetEntityDeclHandler was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol XML_Parse was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol XML_GetErrorCode was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol XML_ErrorString was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol XML_ParserFree was referenced from module /usr/local/etc/httpd/lib/libaprutil-1.so(), but a runtime definition of the symbol was not found. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 68970] mod_deflate no longer properly handles chunked responses from CGI scripts
https://bz.apache.org/bugzilla/show_bug.cgi?id=68970 Eric Covener changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #18 from Eric Covener --- (In reply to Allan Schrum from comment #17) > You arguments indicate that you believe this should never have worked. Fine, > I accept that. However, it did work for a very long time and it is now > broken. Perhaps this worked because previously the code treated the output > from CGI as a transfer hop so Transfer-Encoding worked as Apache read the > output from the CGI process. It was mentioned that the code change that > "broke" this now clears the transfer encoding variable arbitrarily. Perhaps > it should only be cleared if Content-Length is provided? > > So it seems like the options are: > > 1. Go back to the previous behavior for mod_deflate so that the chunked > output from the CGI script is properly read as part of the activities of > mod_deflate. > 1.a. This might need to be more generic and apply to anything reading the > output of the CGI process, not simply mod_deflate. > 1.b. Basically, revert the code change. > 2. Declare victory as Apache httpd is now finally following the standard(s) > 3. Disable mod_deflate > 4. Convert our CGI processes to be NPH #1 isn't likely when we could just add or extend an opt-out as described in Comment #7 > Maybe we could allow extend the "ap_trust_cgilike_cl" interpretation to also > allow T-E. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 68970] mod_deflate no longer properly handles chunked responses from CGI scripts
https://bz.apache.org/bugzilla/show_bug.cgi?id=68970 --- Comment #17 from Allan Schrum --- You arguments indicate that you believe this should never have worked. Fine, I accept that. However, it did work for a very long time and it is now broken. Perhaps this worked because previously the code treated the output from CGI as a transfer hop so Transfer-Encoding worked as Apache read the output from the CGI process. It was mentioned that the code change that "broke" this now clears the transfer encoding variable arbitrarily. Perhaps it should only be cleared if Content-Length is provided? So it seems like the options are: 1. Go back to the previous behavior for mod_deflate so that the chunked output from the CGI script is properly read as part of the activities of mod_deflate. 1.a. This might need to be more generic and apply to anything reading the output of the CGI process, not simply mod_deflate. 1.b. Basically, revert the code change. 2. Declare victory as Apache httpd is now finally following the standard(s) 3. Disable mod_deflate 4. Convert our CGI processes to be NPH The NPH approach is odd because its existence means that the standard CGI response does have headers which are parsed by the daemon. If this worked previously because the output of the CGI process was treated as a transfer hop so that the Transfer-Encoding header was parsed and understood by the daemon, I'd prefer we go back to that behavior. It is clean, simple, and still fits within the concepts of CGI. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 68970] mod_deflate no longer properly handles chunked responses from CGI scripts
https://bz.apache.org/bugzilla/show_bug.cgi?id=68970 --- Comment #16 from Joe Orton --- (In reply to Ruediger Pluem from comment #13) > I have serious trouble to understand how that should have ever worked with > mod_deflate even before 2.4.59. Ah, good point. I tested with 2.4.52 and it compresses the entire response body including chunk-size lines (1). So yeah, not obvious at all how this ever worked with DEFLATE configured. GET /cgi-bin/big-chunks.pl HTTP/1.1 Host: localhost:8052 Accept-Encoding: deflate, gzip HTTP/1.1 200 OK Date: Fri, 10 May 2024 08:07:07 GMT Server: Apache/2.4.52 (Unix) OpenSSL/3.0.9 Transfer-Encoding: chunked Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 67 Content-Type: text/plain �A ��%�e�:�Ls��5��'�i� 7^�@^C -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 68970] mod_deflate no longer properly handles chunked responses from CGI scripts
https://bz.apache.org/bugzilla/show_bug.cgi?id=68970 --- Comment #15 from Ruediger Pluem --- (In reply to Allan Schrum from comment #10) > > With 2.4.59 that is not what is happening. The output of the CGI process has > all its headers thrown away so that the content cannot be processed. Those > headers are part of the CGI response and are allowed by standard. I don't > understand why years of processing these types of responses suddenly must > treat Transfer-Encoding as something magical to be disregarded. https://datatracker.ietf.org/doc/html/rfc3875#section-6.3.4: The script MUST NOT return any header fields that relate to client-side communication issues and could affect the server's ability to send the response to the client. The server MAY remove any such header fields returned by the client. It SHOULD resolve any conflicts between header fields returned by the script and header fields that it would otherwise send itself. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 68970] mod_deflate no longer properly handles chunked responses from CGI scripts
https://bz.apache.org/bugzilla/show_bug.cgi?id=68970 --- Comment #14 from Ruediger Pluem --- (In reply to Allan Schrum from comment #10) > > Enter mod_deflate. It wants to change the response of any request (not > necessarily just a CGI response) so that it is compressed to reduce network > load. To do so it must insert itself in the response stream. Within this > conceptual httpd daemon it should be at the output of the daemon acting as > an intermediate client. It reads the HTTP response from the daemon, > compresses it, wraps it with chunked output, and sends it on its way. Using > this conceptual model, with mod_deflate between the Apache httpd daemon and > the client, mod_deflate must properly read the response in order to compress > the response. This might mean de-chunking that response in order for it to > be compressed. Unfortunately your understanding on how this works is wrong. mod_deflate is applied before the HTTP protocol layer. mod_deflate expects a byte stream as input not a HTTP response that can have a transfer encodings applied. Of course mod_deflate interacts with the HTTP protocol by taking care to unset a e.g. Content-Length or Content-MD5 header as they get invalid due to the compression. It also adjusts ETag headers if requested. But the response body is just taken as is and not subject to any dechunking. Hence my question elsewhere for a minimal configuration that demonstrates that this works with mod_deflate prior to 2.4.59. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 68970] mod_deflate no longer properly handles chunked responses from CGI scripts
https://bz.apache.org/bugzilla/show_bug.cgi?id=68970 --- Comment #13 from Ruediger Pluem --- (In reply to Allan Schrum from comment #12) > You missed the first post which showed 2.4.59 with mod_deflate disabled > allowed the request to process correctly. It demonstrated that mod_deflate > is the critical difference that causes the problem. Exactly why this is > caused by mod_deflate is an internal discussion but it was pointed out > exactly which commit induces this problem. > > Viewed different, this has been working correctly since 2010. For it to > suddenly stop working should be the issue. How to interpret CGI is missing > the point that this had been working from Apache httpd 2.2.x until 2.4.59. > Now it is broken. I have serious trouble to understand how that should have ever worked with mod_deflate even before 2.4.59. Hence I asked for a minimal configuration that makes it possible to understand if and how that could ever worked. Unfortunately this configuration was never given. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
