Re: [PATCH] Fix settings options with ProxyPassMatch
Hi Jan,
sorry for the late.
On Tue, Apr 22, 2014 at 3:39 PM, Jan Kaluža wrote:
> Hi again,
>
> the patch has been here for some time already. I hesitate to commit it to
> trunk without any review, because it changes the core code in mod_proxy and
> I'm afraid that there could exist more corner-cases I'm not aware of.
>
> On the other side (and to motivate someone with deeper knowledge of
> mod_proxy :) ), it would be great to have UDS support also for
> ProxyPassMatch and fix some old bugs related to setting options together
> with ProxyPassMatch (like PR 43513 and PR 54973).
>
> So, anyone who would have time to review this patch, please? :)
I slightly modified your patch with the following changes :
1. Use \-escaping instead of %-escaping for wildcard_match so to
consume less space and unescape quickly.
2. Fix the recursion in ap_proxy_wildcard_match(), which was calling
the legacy ap_strcmp_match(), and unescape according to 1.
2'. Shouldn't this function be made iterative (it is not final
recursive currently)?
3. Always try to get the worker with its de_socketfy()ed name, and
only if not found use ap_proxy_define[_wildcard]_worker() with the
configured URL (add_pass() and proxysection() were not consistent
about ap_proxy_get_worker()'s given name/URL).
4. Don't match both the "normal" name with strcnmp() and the wildcard
name with strcmp_match() in ap_proxy_get_worker(), since the worker is
either wildcard or not (this enforcement is also added to add_pass()
and proxysection() so that it is not possible to declare the same
worker name once with a Match, again without, or vice versa).
4'. Does it makes sense to use the longest match_name or should we go
for the first matching wildcard worker (if any) wins?
5. Rename ap_proxy_wildcard_match() as ap_proxy_strcmp_ematch() to
suggest it could go to server/util.ch (if/when the associated
ap_matchexp_escape() and ap_proxy_strcasecmp_ematch() are coded).
6. Move proxy_worker_shared { char
wildcard_name[PROXY_WORKER_MAX_NAME_SIZE]; } to proxy_worker { char
*match_name; } to save shm space and avoid length issues (I don't see
how this could be updated at runtime, for now, balancer-manager can't
declare Match workers).
6. Keep ap_proxy_escape_wildcard_url() static (private) since it is
not used outside proxy_util (now).
This is not very tested (yet), I'll come back if I detect issues, but
first I'd like your feedbacks on this modifications...
Patch attached.
Regards,
Yann.
trunk-mod_proxy-Match.patch
Description: application/download
Re: svn commit: r1384924 - in /httpd/httpd/trunk: include/httpd.h server/request.c
On 24 Apr 2014, at 8:34 AM, Christophe JAILLET wrote: > the comment is wrong. > > 'ap_sub_req_lookup_dirent' uses the fact that 'rnew->uri' has some extra > space after the NUL. > 'rnew->uri' is allocated via 'ap_escape_uri' which is defined as: > > #define ap_escape_uri(ppool,path) ap_os_escape_path(ppool,path,1) > > So, what matters here is the case in 'ap_os_escape_path' where partial *is* > set. > > However, I have commited r1589599 in order to update the comment and to > allocate one extra byte to be safe, even if not needed in this particular > case. Soon this will get replaced by the apr_escape API, which will allocate the precise amount of space for each buffer. We must make sure that code is relying on side effects of the original code. The apr_escape API will allow you to ask for the required amount of space, which you can then manipulate before allocating the space, we must just be clear should we need to do this. Regards, Graham --
Re: SSL backend via ProxyRemote (using CONNECT)
On Thu, Apr 24, 2014 at 3:37 PM, Yann Ylavic wrote: > On Thu, Apr 24, 2014 at 3:29 PM, Plüm, Rüdiger, Vodafone Group > wrote: >> >> IMHO this is a flaw of the backend as IMHO full URL's are allowed also in >> non proxy cases by the RFC. > > I agree, but I can't do anything on the (broken) backend side, proxy only... > I can live with my patch, but mod_proxy isn't doing the right thing > either, IMHO. Moreover, in the case the backend handles full URLs, the host name from there has precedence, which makes the Host header ignored, and may break things like ProxyPreserveHost (suppose IP addresses are used in ProxyPass declarations)... > > Regards, > Yann.
Re: SSL backend via ProxyRemote (using CONNECT)
On Thu, Apr 24, 2014 at 3:29 PM, Plüm, Rüdiger, Vodafone Group wrote: > > IMHO this is a flaw of the backend as IMHO full URL's are allowed also in non > proxy cases by the RFC. I agree, but I can't do anything on the (broken) backend side, proxy only... I can live with my patch, but mod_proxy isn't doing the right thing either, IMHO. Regards, Yann.
RE: SSL backend via ProxyRemote (using CONNECT)
> -Original Message- > From: Yann Ylavic [mailto:ylavic@gmail.com] > Sent: Donnerstag, 24. April 2014 15:05 > To: httpd > Subject: SSL backend via ProxyRemote (using CONNECT) > > Hello, > > with the following (chained) configuration : > > > ServerName reverse-proxy > ProxyPass / https://backend:443/ > ProxyRemote * http://proxy:8080 > #ProxyRequests off > > > > ServerName forward-proxy > ProxyRequests on > > > > ServerName backend > ## Whatever ### > > > Then, when the reverse-proxy receives a request-line like : > GET /index.php HTTP/1.1 > Host: reverse-proxy > ... > > It forwards this one(s) to the backend : > > CONNECT backend:443 HTTP/1.0 > < HTTP/1.0 200 Established > < SSL stream now (note the full URL in the request-line) > > GET https://backend/index.php HTTP/1.1 > Host: backend > ... > > I agree that ProxyRemote is supposed to be a forward proxy (hence the > full URL when requesting plain HTTP through it, with GET > http://backend/index.php HTTP/1.1), but the final backend is not (and > may even refuse full URLs, which is actually a case I'm facing). IMHO this is a flaw of the backend as IMHO full URL's are allowed also in non proxy cases by the RFC. Regards Rüdiger
Re: mod_ssl: TLS/HTTPS multiplexing with other protocols
On 23 Apr 2014, at 8:39 PM, Daniel Pocock wrote: > This brings me to the observation that something needs to do the TLS > handshake and then look at the request body from the client (e.g. the > HTTP request line or SIP request line) to work out what type of request > it is. All of the following are obviously very easy to distinguish from > each other: > > HTTP: > GET / HTTP/1.1 > > SIP: > INVITE sip:dan...@pocock.pro SIP/1.0 > > XMPP: > > > > so there may be two ways to go about this: > > a) the user's preferred process (possibly Apache httpd) will do the > handshake, inspect the request line and then tunnel the data stream to > some other server when appropriate > > b) some new process would be created (like sshttpd) to do the handshake > and then route the data to whichever server is appropriate (httpd, SIP > proxy, XMPP server, ...) > > In either case, it is very desirable for the process that does the > handshake to relay some data about the client (source IP, client > certificate identity parameters) to the process that is responsible for > the protocol. > > Is anybody aware of any existing work in any of these areas, even if it > is just discussion about the optimal architecture or the type of > solution that the Apache community would prefer if somebody worked on this? Not aware specifically about anything like this, but it is certainly possible to do this. What you want is a connection filter that looks out for "INVITE * SIP/1.0" and then handles the connection if seen in some fashion, even if this is as simply as proxy the connection to a real SIP server. Same is possible with XMPP. Sounds like a sensible thing to do. Regards, Graham --
SSL backend via ProxyRemote (using CONNECT)
Hello,
with the following (chained) configuration :
ServerName reverse-proxy
ProxyPass / https://backend:443/
ProxyRemote * http://proxy:8080
#ProxyRequests off
ServerName forward-proxy
ProxyRequests on
ServerName backend
## Whatever ###
Then, when the reverse-proxy receives a request-line like :
GET /index.php HTTP/1.1
Host: reverse-proxy
...
It forwards this one(s) to the backend :
> CONNECT backend:443 HTTP/1.0
< HTTP/1.0 200 Established
< SSL stream now (note the full URL in the request-line) >
GET https://backend/index.php HTTP/1.1
Host: backend
...
I agree that ProxyRemote is supposed to be a forward proxy (hence the
full URL when requesting plain HTTP through it, with GET
http://backend/index.php HTTP/1.1), but the final backend is not (and
may even refuse full URLs, which is actually a case I'm facing).
Am I missing something or should this be fixed when CONNECT is used by
ProxyRemote?
In the latter case, should it depend on "ProxyRequests off" only (to
not break existing)?
That could be done with this patch (where ProxyRequests' dependency is
commented out):
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c(revision 1589129)
+++ modules/proxy/proxy_util.c(working copy)
@@ -2186,7 +2313,7 @@ ap_proxy_determine_connection(apr_pool_t *p, reque
* short living pool.
*/
/* are we connecting directly, or via a proxy? */
-if (!proxyname) {
+if (!proxyname || (conn->is_ssl/* && conf->req_set && !conf->req*/)) {
*url = apr_pstrcat(p, uri->path, uri->query ? "?" : "",
uri->query ? uri->query : "",
uri->fragment ? "#" : "",
[END]
Regards,
Yann.
