Re: mod_proxy_html and special characters
>> ctx->buf = http://internal/!%22%23$/ >> m->from.c = http://internal/!"#$/ A further thought arising from that. Just as strcasecmp is case-independent, the world could no doubt use a standard library function that would treat the above as equal. Something like int stringcmp(const char *a, const char *b, unsigned int flags) where flags would control behaviour such as case-independence, and equivalence over URLencoding, HTML encoding, HTML entities, and whatever else someone might like to support (maybe integrate with locale too?). Anyone know of such a thing? -- Nick Kew
Re: mod_proxy_html and special characters
> On 28 May 2018, at 08:50, Micha Lenk wrote: > > The reason I am asking this is, because for Location matching, Apache httpd > apparently does map a request with a URL encoded path to the non-encoded > configured path. For example, if I have configured in a virtual host: Yes of course httpd deals with encoding, as it must, in processing a request URL. > >ProxyPass "http://internal/!\"#$/"; >ProxyHTMLURLMap "http://internal/!\"#$/"; "http://external/!\"#$/"; >... > mod_proxy_html is not processing a request URL, it's processing contents in the response. Contents destined, and encoded, for a HTTP Client. The resemblence is entirely coincidental. To align the behaviour on grounds of consistency would seem to me misleading! -- Nick Kew
Re: mod_proxy_html and special characters
Hi Eric, On 05/25/2018 06:57 PM, Eric Covener wrote: http://internal/!%22%23$/";>A link with special characters >> ProxyHTMLURLMap "http://internal/!\"#$/"; "http://external/!\"#$/"; Is it reasonable to expect mod_proxy_html to rewrite URL encoded URLs as well? > IMO no, I don't think the literals in the first argument should be expected to match the URL-encoded content The reason I am asking this is, because for Location matching, Apache httpd apparently does map a request with a URL encoded path to the non-encoded configured path. For example, if I have configured in a virtual host: ProxyPass "http://internal/!\"#$/"; ProxyHTMLURLMap "http://internal/!\"#$/"; "http://external/!\"#$/"; ... ... then for matching the location container it does not matter whether the path of the request is URL encoded or not. I consider this behavior a bit inconsistent. URL-encoded requests get proxied to the internal resource as if they were not URL-encoded. But URL-encoding a few characters in the path is sufficient to bypass HTML rewriting. Regards, Micha
