For clarity's sake, the spec defines these two entities as not-equal.
Of course, %41 and 'A' are equivilant, so such a function might not be a
bad thing to have in refactoring URI handling.
On Mon, May 28, 2018, 04:10 Nick Kew wrote:
>
> >> ctx->buf = http://internal/!%22%23$/
> >> m->from.c =
>> 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, co
> 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
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 lite
> On 25 May 2018, at 17:43, Micha Lenk wrote:
>
> 524 s_from = strlen(m->from.c);
> 525 if (!strncasecmp(ctx->buf, m->from.c, s_from)) {
> ... ... do the string replacement ...
>
>
> ... where ctx->buf is the URL found in the HTML document, and m->fro
On Fri, May 25, 2018 at 11:57 AM, 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
> 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 mat