Use case: connect to a http backend over Unix Domain Socket connecting http://localhost/a/b/c/d.e.1%3F$select=foo?$select=foo to localhost:80 in 2.4.53 we are seeing connecting http://localhost/a/b/c/d.e.1?$select=foo to localhost:80
Can you please provide your configuration?
I am using below config. RewriteCond %{REQUEST_URI} ^/a/b.* RewriteRule (.*) unix:/run/tmservice/http.socket|http://localhost%{REQUEST_URI} [P,NE]
you might try one of: RewriteRule (.*) unix:/run/tmservice/http.socket|http://localhost%{REQUEST_URI} [P,NE,E=proxy-nocanon:1] or RewriteRule (.*) - [H=unix:/run/tmservice/http.socket|http://localhost%{REQUEST_URI}]
Is this rewriterule in virtual server or in directory context?
we are using direct context.
(In reply to venki from comment #5) > we are using direct context. Sorry for being pedantic here. You meant to say directory context?
When you observe the issue do you use 2.4.62 plus the patch from PR 69235?
Yes, I have applied the patch PR 69235 on 2.4.62 for the fcgi backend socket connect. I am using directory context, and adding the Apache config and log. <LocationMatch ^/a> RewriteEngine On RewriteCond %{REQUEST_URI} ^/a/b(.*) RewriteRule (.*) unix:/var/run/http.socket|http://localhost%{REQUEST_URI} [P,NE] </LocationMatch> observing below log. connecting http://localhost/a/b/c/d.e.1%3F$select=foo?$select=foo to localhost:80
Created attachment 39842 [details] Additional patch for PR 69235 Please try the attached patch on top of the one from PR 69235.
I see different in the lines between provided patch and 2.4.62 code. 2.4.62 lines: ------------------------- 5223 if (ACTION_STATUS == rulestatus) { 5224 int n = r->status; 5225 5226 r->status = HTTP_OK; 5227 return n; 5228 } 5229 else if (ACTION_STATUS_SET == rulestatus) { 5230 return r->status; 5231 } 5232 5233 if (to_proxyreq) { 5234 /* it should go on as an internal proxy request */ 5235 5236 /* make sure the QUERY_STRING and 5237 * PATH_INFO parts get incorporated 5238 * (r->path_info was already appended by the 5239 * rewriting engine because of the per-dir context!) 5240 */ 5241 if (r->args != NULL) { 5242 /* see proxy_http:proxy_http_canon() */ 5243 r->filename = apr_pstrcat(r->pool, r->filename, 5244 "?", r->args, NULL); 5245 } patch file: ----------------- return HTTP_FORBIDDEN; 5393 } 5379 } 5394 5380 5395 /* make sure the QUERY_STRING and 5381 if (rulestatus == ACTION_NOESCAPE) { 5396 * PATH_INFO parts get incorporated 5382 apr_table_setn(r->notes, "proxy-nocanon", "1"); 5383 } 5384 5385 /* make sure the QUERY_STRING gets incorporated, but only 5386 * if we do not escape the target. Otherwise the mod_proxy 5387 * canon handler will take care to do this. 5397 * (r->path_info was already appended by the 5388 * (r->path_info was already appended by the 5398 * rewriting engine because of the per-dir context!) 5389 * rewriting engine because of the per-dir context!) 5399 */ 5390 */ 5400 if (r->args != NULL) { 5391 if ((r->args != NULL) && (rulestatus == ACTION_NOESCAPE)) { 5401 /* see proxy_http:proxy_http_canon() */ 5392 /* see proxy_http:proxy_http_canon() */ 5402 r->filename = apr_pstrcat(r->pool, r->filename, 5393 r->filename = apr_pstrcat(r->pool, r->filename, 5403 "?", r->args, NULL); 5394 "?", r->args, NULL); 5246 Could you pls suggest the line numbers and above rulestatus checks.
Don't worry. As this is a unified patch the patch program will apply it correctly. The patch is against trunk and hence the differences in line numbers. I crosschecked that the patch applies against the 2.4.x branch as well.
*** This bug has been marked as a duplicate of bug 69235 ***