Bug 58467 - Environment Variables in ProxyHTMLURLMap produces Warnings
Summary: Environment Variables in ProxyHTMLURLMap produces Warnings
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_html (show other bugs)
Version: 2.4-HEAD
Hardware: PC All
: P2 major with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-29 17:06 UTC by Stefan Greiner
Modified: 2023-05-04 15:20 UTC (History)
5 users (show)



Attachments
Candidate fix (1.01 KB, patch)
2017-12-16 22:20 UTC, Nick Kew
Details | Diff
possible fix (2.31 KB, patch)
2023-05-03 18:29 UTC, Stefan G
Details | Diff
backward compatible fix (2.76 KB, patch)
2023-05-04 15:20 UTC, Stefan G
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Greiner 2015-09-29 17:06:41 UTC
Apache 2.4.XX example which will produce a warning:

RewriteRule ^/path/(foo|bar)/(.*)$ - [E=mypath:$1]
<LocationMatch "/path/(foo|bar)/.*">
	SetOutputFilter proxy-html
	ProxyHTMLInterp On
	ProxyHTMLURLMap ^/a/path/to/change/(.*)$ /newpath/${mypath}/images/$1 ecRiLV
</LocationMatch>

This is how the documentation of proxy_html is telling us to use environment variables.

Syntax Check or Startup Warning will be the following:

[Tue Sep 29 18:30:08.800644 2015] [core:warn] [pid 3114:tid 140660994774912] AH00111: Config variable ${mypath} is not defined


In my opinion the config should be written since Apache 2.4 like this as the notation of environmental variables has changed:

RewriteRule ^/path/(foo|bar)/(.*)$ - [E=mypath:$1]
<LocationMatch "/path/(foo|bar)/.*">
	SetOutputFilter proxy-html
	ProxyHTMLInterp On
	ProxyHTMLURLMap ^/a/path/to/change/(.*)$ /newpath/%{ENV:mypath}/images/$1 ecRiLV
</LocationMatch>

But if I use it this way, the replacement of the variable is no longer working, it writes down the url encoded representation of it into the path: %25%7BENV%3Amypath%7D

Conclusion:
Either the warning should be removed here or the way of noting variables should be changed to comply with Apache 2.4 environment variable notation style.
Comment 1 Guido 2016-05-09 14:46:27 UTC
Hi, 
Is there a work-around for this issue? 

Thanks
Comment 2 Stefan Greiner 2016-05-09 15:17:18 UTC
ProxyHTMLURLMap works if used with the for environment vars wrong ${varname} notation but produces the mentioned warnings. This is kind of a workaround.

But the notation ${varname} is only allowed for variables defined with Define or -D at startup, it is not valid for environmental variables so the apache warning under 2.4.x is correct.

If used with the %{ENV:varname} notation it does not work at all. So the module is using 2.2.x syntax under 2.4.x and therefore needs a bugfix.
Comment 3 Stefan Greiner 2017-10-27 07:26:35 UTC
May I ask for an update? The bug is still in the 2.4 Code...
Comment 4 Nick Kew 2017-12-16 21:21:04 UTC
> May I ask for an update? The bug is still in the 2.4 Code...

Sorry, I've only just looked at this.  Looks like it would indeed be a Good Idea to change it: the mod_proxy_html syntax pre-dates the config variable changes that interact with it to produce the error.

I'll have a think about this: your suggestion looks like a candidate fix, but maybe using the expression parser could add something more!
Comment 5 Nick Kew 2017-12-16 22:20:52 UTC
Created attachment 35617 [details]
Candidate fix

Does the attached patch do the job for you?
Comment 6 Techiq 2018-05-08 00:10:28 UTC
Apache 2.4.XX example which will produce a warning:

RewriteRule ^/path/(foo|bar)/(.*)$ - [E=mypath:$1]
<LocationMatch "/path/(foo|bar)/.*">
	SetOutputFilter proxy-html
	ProxyHTMLInterp On
	ProxyHTMLURLMap ^/a/path/to/change/(.*)$ /newpath/${mypath}/images/$1 ecRiLV
</LocationMatch>

This is how the documentation of proxy_html is telling us to use environment variables.

Syntax Check or Startup Warning will be the following:

[Tue Sep 29 18:30:08.800644 2015] [core:warn] [pid 3114:tid 140660994774912] AH00111: Config variable ${mypath} is not defined


In my opinion the config should be written since Apache 2.4 like this as the notation of environmental variables has changed:

RewriteRule ^/path/(foo|bar)/(.*)$ - [E=mypath:$1]
<LocationMatch "/path/(foo|bar)/.*">
	SetOutputFilter proxy-html
	ProxyHTMLInterp On
	ProxyHTMLURLMap ^/a/path/to/change/(.*)$ /newpath/%{ENV:mypath}/images/$1 ecRiLV
</LocationMatch>

But if I use it this way, the replacement of the variable is no longer working, it writes down the url encoded representation of it into the path: %25%7BENV%3Amypath%7D

Conclusion:
Either the warning should be removed here or the way of noting variables should be changed to comply with Apache 2.4 envir
Comment 7 Techiq 2018-05-08 00:11:54 UTC
Comment on attachment 35617 [details]
Candidate fix

Apache 2.4.XX example which will produce a warning:

RewriteRule ^/path/(foo|bar)/(.*)$ - [E=mypath:$1]
<LocationMatch "/path/(foo|bar)/.*">
	SetOutputFilter proxy-html
	ProxyHTMLInterp On
	ProxyHTMLURLMap ^/a/path/to/change/(.*)$ /newpath/${mypath}/images/$1 ecRiLV
</LocationMatch>

This is how the documentation of proxy_html is telling us to use environment variables.

Syntax Check or Startup Warning will be the following:

[Tue Sep 29 18:30:08.800644 2015] [core:warn] [pid 3114:tid 140660994774912] AH00111: Config variable ${mypath} is not defined


In my opinion the config should be written since Apache 2.4 like this as the notation of environmental variables has changed:

RewriteRule ^/path/(foo|bar)/(.*)$ - [E=mypath:$1]
<LocationMatch "/path/(foo|bar)/.*">
	SetOutputFilter proxy-html
	ProxyHTMLInterp On
	ProxyHTMLURLMap ^/a/path/to/change/(.*)$ /newpath/%{ENV:mypath}/images/$1 ecRiLV
</LocationMatch>

But if I use it this way, the replacement of the variable is no longer working, it writes down the url encoded representation of it into the path: %25%7BENV%3Amypath%7D

Conclusion:
Either the warning should be removed here or the way of noting variables should be changed to comply with Apache 2.4 envir
Comment 8 Stefan G 2023-05-02 09:38:35 UTC
I just stumbled upon this bug again. When will the fix hit the production version?
Comment 9 Stefan G 2023-05-03 18:29:11 UTC
Created attachment 38552 [details]
possible fix

I created a pull request on GitHub similar to the provided candidate fix.
Maybe it gets accepted and we can close this bug after 8 years.
Also I changed the docs in that PR.

https://github.com/apache/httpd/pull/358
Comment 10 Stefan G 2023-05-04 15:20:54 UTC
Created attachment 38553 [details]
backward compatible fix