[Bug 65093] with UseCanonicalName=Off, the server should still use only known Names
https://bz.apache.org/bugzilla/show_bug.cgi?id=65093 --- Comment #1 from Christoph Anton Mitterer --- And as a small side note (which I don't quite understand): If I do in my testing the very same as described above, but with mod_dir disabled it does "work". That is: Despite the missing trailing / in the case (a), no redirect is generated and mod_autoindex generates the very same output than in case (b). >From how I had understood the documentation, mod_autoindex shouldn't have done this. -- 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 65093] with UseCanonicalName=Off, the server should still use only known Names
https://bz.apache.org/bugzilla/show_bug.cgi?id=65093 Christoph Anton Mitterer changed: What|Removed |Added Summary|with UseCanonicalName=Off, |with UseCanonicalName=Off, |the server should still |the server should still use |respond only with known |only known Names |Names | -- 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 65093] New: with UseCanonicalName=Off, the server should still respond only with known Names
https://bz.apache.org/bugzilla/show_bug.cgi?id=65093 Bug ID: 65093 Summary: with UseCanonicalName=Off, the server should still respond only with known Names Product: Apache httpd-2 Version: 2.5-HEAD Hardware: All OS: All Status: NEW Severity: enhancement Priority: P2 Component: Core Assignee: bugs@httpd.apache.org Reporter: cales...@scientia.net Target Milestone: --- Hey. Probably the following has been already asked somewhere and I just couldn't find it or there's a perfect reason which things are as they are and I'm too dumb to see it ^^ ... if so simply close. First, on a request(!), the server - as documented in the vhost docs - ignores any Port in the Host: header but instead uses the real port of the connection for selecting the vhost candidates. Which is fine of course. Behaviour or documentation is already a bit odd though, cause when using e.g. it would implicitly add some.domain.name.com:8080 (it seems *with* the port) to ServerAliases (as documented) - while ServerAlias doesn't even allow a port? Nevertheless, that's not the point of this issue: As the documentation of UseCanonicalName says, a value of "Off", makes httpd really use exactly the client provided Host: [addr|name]:port header for any redirects (and also for generated content like error messages in the response body). And it would also use it literally (from the client Host: header) for CGI vars and that like I think it might be an improvement (and in case of poorly written CGIs, even a security improvement) if it would do so only with a certain restriction, namely: Only use the client's value if it's really a valid hostname and port of the vhost where the request ended up being processed and if not... use the vhosts canonical name and the port of the connection. If one ends up in an IP-based vhost,... and the client's name/port don't match the configured ones of the vhost, use the canonical ServerName of the vhost and the port of the connection. If one ends up in a name based vhost,... well if it's *not* the default-vhost for a certain name:port combination, one is anyway sure that the client provided value must have matched a ServerName/Alias of the vhost. But if one ended up in the default (firts listed) vhost, the client might have specified anything for name:port and ended up there. Anything for the name, because the default vhost would catch it, and anything for the port, because the Host: header port is ignored during vhost matching. For testing I used a setup like this: - DNS: example.com default.example.com other.example.com all pointing to e.g. 10.10.10.10 - the server listening *.80 - two name based vhosts default.example.com (being the first listed one) other.example.com - both having this as their ServerName set - both vhosts listening on the same addr:port like 10.10.10.10:80 - mod_dir enabled - auto index enabled for /123/ Two requests: a) wget --debug --content-on-error -4 -O - --header="Host: foo.bar:666" http://example.com/123 b) wget --debug --content-on-error -4 -O - --header="Host: foo.bar:666" http://example.com/123/ - both will reach the server - both will end up in the default.example.com vhost as foo.bar is unknown but the connection IP matches the vhost IPs ... and the Host: port is ignored anyway - (b) having the trailing / won't cause a redirect and show the dir listing - (a) lacking the trailing / will cause a redirect, with http using foo.bar:666, for which we know it's definitely wrong. The server can know, that only any valid [addr|name]:port combination for the vhost "default.example.com" would be a valid hostname (canonical or not). And as such if there is no match, it should use the ServerName of default.example.com and *independently* if there's no match for the port, the port of the connection. Cheers, Chris. -- 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 65091] htcacheclean displays only one cache files when few exists in one subdirectory
https://bz.apache.org/bugzilla/show_bug.cgi?id=65091 Artem Egorenkov changed: What|Removed |Added Keywords||PatchAvailable -- 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 65091] htcacheclean displays only one cache files when few exists in one subdirectory
https://bz.apache.org/bugzilla/show_bug.cgi?id=65091 Artem Egorenkov changed: What|Removed |Added CC||aegorenkov...@gmail.com --- Comment #1 from Artem Egorenkov --- Created attachment 37705 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37705&action=edit Patch fixing the described problem TEST: # htcacheclean -p . -A http://192.168.122.75:80/small_image_files/a_020.jpg? 556 27331 200 0 1611046420286395 1611054168715034 1611046420286096 1611046420286395 1 0 http://192.168.122.75:80/small_image_files/a_052.jpg? 557 77684 200 0 1611046420291158 1611054168720273 1611046420290791 1611046420291158 1 0 # echo $? 0 -- 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 65091] New: htcacheclean displays only one cache files when few exists in one subdirectory
https://bz.apache.org/bugzilla/show_bug.cgi?id=65091 Bug ID: 65091 Summary: htcacheclean displays only one cache files when few exists in one subdirectory Product: Apache httpd-2 Version: 2.4.37 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: support Assignee: bugs@httpd.apache.org Reporter: aegorenkov...@gmail.com Target Milestone: --- Sometimes there are few files in one cache subdirectory. In this case using of "htcacheclean -p . -A" will only show one record. How to reproduce: 1. # cat /etc/httpd/conf.d/cache.conf CacheRoot /var/cache/httpd/proxy CacheEnable disk "/" CacheDirLevels 1 2. static html with multiple pictures created in /var/www/html/ I just saved ddg image search page with random request 3. access static html with web browser cache content should be generated # ls -l /var/cache/httpd/proxy/9E/ total 112 -rw---. 1 apache apache 27331 Jan 19 09:53 kmc7qg8ov2ver7q...@w.data -rw---. 1 apache apache 556 Jan 19 09:53 kMC7qG8oV2vER7QOa5@w.header -rw---. 1 apache apache 77684 Jan 19 09:53 sOsGyFnw7UEH29Jyip0Q.data -rw---. 1 apache apache 557 Jan 19 09:53 sOsGyFnw7UEH29Jyip0Q.header 4. # cd /var/cache/httpd/proxy/9E/ Actual result: # htcacheclean -p . -A http://192.168.122.75:80/small_image_files/a_020.jpg? 556 27331 200 0 1611046420286395 1611054168715034 1611046420286096 1611046420286395 1 0 Expected result: # htcacheclean -p . -A http://192.168.122.75:80/small_image_files/a_020.jpg? 556 27331 200 0 1611046420286395 1611054168715034 1611046420286096 1611046420286395 1 0 http://192.168.122.75:80/small_image_files/a_052.jpg? 557 77684 200 0 1611046420291158 1611054168720273 1611046420290791 1611046420291158 1 0 -- 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 64810] Unable to proxy requests to a secured websockets (wss) in 2.4.41
https://bz.apache.org/bugzilla/show_bug.cgi?id=64810 Yann Ylavic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- 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
