uds support
I'm scrapping some of the work I've been doing, simply because, from what I can see, using the current method of specifying it creates problems. Instead, I'm looking into something like: http://localhost/var/run/server.sock|/foo/bar For ease of parsing and clearly breaking out what needs to be encoded, etc. Thus, the path to the socket is: /var/run/server.sock and the URL is /foo/bar Thoughts? Comments?
Re: uds support
On 23 Aug 2013, at 15:05 (UTC-0400), Jim Jagielski wrote: > I'm scrapping some of the work I've been doing, simply because, from what I > can see, using the current method of specifying it creates problems. > > Instead, I'm looking into something like: > > http://localhost/var/run/server.sock|/foo/bar > > For ease of parsing and clearly breaking out what needs to be encoded, etc. My different suggestion is unixsocket+http:/var/run/server.sock://foo/bar It's nonstandard but then there's no real way to avoid that. The "://" bit should stick out clearly enough to people who are used to HTTP URIs. If rewriting, etc yields something like http+uds:/var/run/server.sock://foo/bar://etc/passwd then the socket is "/var/run/server.sock" and the request line will be for "//foo/bar://etc/passwd". This allows a possibility of identifying alternative protocols if they turn up, eg https, ajp. -- Tim Bannister – is...@jellybaby.net
Re: uds support
On Aug 23, 2013, at 3:37 PM, Tim Bannister wrote: > On 23 Aug 2013, at 15:05 (UTC-0400), Jim Jagielski wrote: > >> I'm scrapping some of the work I've been doing, simply because, from what I >> can see, using the current method of specifying it creates problems. >> >> Instead, I'm looking into something like: >> >> http://localhost/var/run/server.sock|/foo/bar >> >> For ease of parsing and clearly breaking out what needs to be encoded, etc. > > > My different suggestion is unixsocket+http:/var/run/server.sock://foo/bar > I've also looked at (and am hoping it works out) sock://var/run/server.sock|http://localhost/foo/bar The reason I like using '|' is it's quite Perlish :) The other advantage is that it keep both "sides" completely separate and self-contained.
Re: uds support
On Fri, Aug 23, 2013 at 3:50 PM, Jim Jagielski wrote: > > On Aug 23, 2013, at 3:37 PM, Tim Bannister wrote: > > > On 23 Aug 2013, at 15:05 (UTC-0400), Jim Jagielski wrote: > > > >> I'm scrapping some of the work I've been doing, simply because, from > what I can see, using the current method of specifying it creates problems. > >> > >> Instead, I'm looking into something like: > >> > >> http://localhost/var/run/server.sock|/foo/bar > >> > >> For ease of parsing and clearly breaking out what needs to be encoded, > etc. > > > > > > My different suggestion is unixsocket+http:/var/run/server.sock://foo/bar > > > > I've also looked at (and am hoping it works out) > > sock://var/run/server.sock|http://localhost/foo/bar > > The reason I like using '|' is it's quite Perlish :) > The other advantage is that it keep both "sides" completely > separate and self-contained. > > Your idea would still work fine if it used "fcgi" instead of "http", right? (There could be multiple protocols that use a Unix socket; something should distinguish this as FastCGI.) How would a relative socket path be represented? (assuming we want to support runtimedir) -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: uds support
On 8/23/2013 2:50 PM, Jim Jagielski wrote: > I've also looked at (and am hoping it works out) > > sock://var/run/server.sock|http://localhost/foo/bar > > The reason I like using '|' is it's quite Perlish :) > The other advantage is that it keep both "sides" completely > separate and self-contained. I like this one better... it's definitely the "cleanest" representation. I'm assuming that the post-pipe stuff gets parsed as usual and then 'localhost' gets sent as the Host header (unless ProxyPreserveHost is set)? -- Daniel Ruggeri
Re: uds support
On Aug 27, 2013, at 7:09 PM, Daniel Ruggeri wrote: > On 8/23/2013 2:50 PM, Jim Jagielski wrote: >> I've also looked at (and am hoping it works out) >> >> sock://var/run/server.sock|http://localhost/foo/bar >> >> The reason I like using '|' is it's quite Perlish :) >> The other advantage is that it keep both "sides" completely >> separate and self-contained. > > I like this one better... it's definitely the "cleanest" representation. > I'm assuming that the post-pipe stuff gets parsed as usual and then > 'localhost' gets sent as the Host header (unless ProxyPreserveHost is set)? Yeah... in fact, in my current local branch, this is the format I'm using. It makes things *much* cleaner.
Re: uds support
This value is in the format of a URL; | is in the list of 'unsafe' chars for URLs. Perhaps use semi-colon instead? sock://var/run/server.sock;/foo/bar On Wed, Aug 28, 2013 at 8:00 AM, Jim Jagielski wrote: > > On Aug 27, 2013, at 7:09 PM, Daniel Ruggeri wrote: > > > On 8/23/2013 2:50 PM, Jim Jagielski wrote: > >> I've also looked at (and am hoping it works out) > >> > >> sock://var/run/server.sock|http://localhost/foo/bar > >> > >> The reason I like using '|' is it's quite Perlish :) > >> The other advantage is that it keep both "sides" completely > >> separate and self-contained. > > > > I like this one better... it's definitely the "cleanest" representation. > > I'm assuming that the post-pipe stuff gets parsed as usual and then > > 'localhost' gets sent as the Host header (unless ProxyPreserveHost is > set)? > > Yeah... in fact, in my current local branch, this is the format > I'm using. It makes things *much* cleaner. >
Re: uds support
On 28 Aug 2013, at 17:02, Daniel Lescohier wrote: > This value is in the format of a URL; | is in the list of 'unsafe' chars for > URLs. In this particular case, that could be a good thing. '|' is unsafe partly because of shell expansion, which httpd won't be doing. -- Tim Bannister – is...@jellybaby.net
Re: uds support
Which is why I suggested using it... It is "guaranteed" to not be part of the URL and therefore serves as a good field delim. On Aug 28, 2013, at 12:02 PM, Daniel Lescohier wrote: > This value is in the format of a URL; | is in the list of 'unsafe' chars for > URLs. Perhaps use semi-colon instead? > > sock://var/run/server.sock;/foo/bar > > > > On Wed, Aug 28, 2013 at 8:00 AM, Jim Jagielski wrote: > > On Aug 27, 2013, at 7:09 PM, Daniel Ruggeri wrote: > > > On 8/23/2013 2:50 PM, Jim Jagielski wrote: > >> I've also looked at (and am hoping it works out) > >> > >> sock://var/run/server.sock|http://localhost/foo/bar > >> > >> The reason I like using '|' is it's quite Perlish :) > >> The other advantage is that it keep both "sides" completely > >> separate and self-contained. > > > > I like this one better... it's definitely the "cleanest" representation. > > I'm assuming that the post-pipe stuff gets parsed as usual and then > > 'localhost' gets sent as the Host header (unless ProxyPreserveHost is set)? > > Yeah... in fact, in my current local branch, this is the format > I'm using. It makes things *much* cleaner. >
Re: uds support
On Aug 23, 2013, at 3:50 PM, Jim Jagielski wrote: > > On Aug 23, 2013, at 3:37 PM, Tim Bannister wrote: > >> On 23 Aug 2013, at 15:05 (UTC-0400), Jim Jagielski wrote: >> >>> I'm scrapping some of the work I've been doing, simply because, from what I >>> can see, using the current method of specifying it creates problems. >>> >>> Instead, I'm looking into something like: >>> >>> http://localhost/var/run/server.sock|/foo/bar >>> >>> For ease of parsing and clearly breaking out what needs to be encoded, etc. >> >> >> My different suggestion is unixsocket+http:/var/run/server.sock://foo/bar >> > > I've also looked at (and am hoping it works out) > > sock://var/run/server.sock|http://localhost/foo/bar > > The reason I like using '|' is it's quite Perlish :) > The other advantage is that it keep both "sides" completely > separate and self-contained. > Committed in r1531340 the above is implemented... kinda. I instead went with http://localhost/foo/bar|sock:/var/run.s.sock which worked out just a bit cleaner...
Re: uds support
On Oct 11, 2013, at 12:24 PM, Jim Jagielski wrote: > > Committed in r1531340 the above is implemented... kinda. > I instead went with > > http://localhost/foo/bar|sock:/var/run.s.sock > > which worked out just a bit cleaner... After playing around the above, I find that it's hard to come up with a consistent and logical (non-surprising) way to merge the 2 paths in the 2 uris... especially when you consider that ap_runtime_dir_relative() should really be applied as well. S I'm proposing that we simply drop the "sock:..." part and use 2 things as the "this is a UDS" trigger: 1. hostname is 'localhost' 2. the '|' is the last char of the URL eg: ajp://localhost/./rel/dir/foo.sock| http://localhost/var/tmp/s.sock| Comments?
RE: uds support
The original proposal look more intuitive. Especially the relative path in the ajp example looks hard to understand for the not so experienced. Regards Rüdiger > -Original Message- > From: Jim Jagielski > Sent: Montag, 14. Oktober 2013 15:08 > To: dev@httpd.apache.org > Subject: Re: uds support > > > On Oct 11, 2013, at 12:24 PM, Jim Jagielski wrote: > > > > Committed in r1531340 the above is implemented... kinda. > > I instead went with > > > > http://localhost/foo/bar|sock:/var/run.s.sock > > > > which worked out just a bit cleaner... > > After playing around the above, I find that it's hard to > come up with a consistent and logical (non-surprising) > way to merge the 2 paths in the 2 uris... especially > when you consider that ap_runtime_dir_relative() > should really be applied as well. > > S > > I'm proposing that we simply drop the "sock:..." > part and use 2 things as the "this is a UDS" > trigger: > > 1. hostname is 'localhost' > 2. the '|' is the last char of the URL > > eg: > > ajp://localhost/./rel/dir/foo.sock| > http://localhost/var/tmp/s.sock| > > Comments?
Re: uds support
Which one? sock://var/run/server.sock|http://localhost/foo/bar or http://localhost/foo/bar|sock:/var/run.s.sock I guess we could say that the path info for the "segment" that provides the communication scheme (http://localhost/... above), if any, is ignored. eg: http://localhost/|sock:./rel/dir/s.sock ajp://localhost/ignored/path|sock:/var/run/a.sock Heck, we could even do away w/ sock: and use file: which people understand has relative and abs paths, lacks host, etc... Plus, we avoid creating any "additional" scheme ;) On Oct 14, 2013, at 9:17 AM, Plüm, Rüdiger, Vodafone Group wrote: > The original proposal look more intuitive. Especially the relative path in > the ajp example > looks hard to understand for the not so experienced. > > Regards > > Rüdiger > >> -Original Message- >> From: Jim Jagielski >> Sent: Montag, 14. Oktober 2013 15:08 >> To: dev@httpd.apache.org >> Subject: Re: uds support >> >> >> On Oct 11, 2013, at 12:24 PM, Jim Jagielski wrote: >>> >>> Committed in r1531340 the above is implemented... kinda. >>> I instead went with >>> >>> http://localhost/foo/bar|sock:/var/run.s.sock >>> >>> which worked out just a bit cleaner... >> >> After playing around the above, I find that it's hard to >> come up with a consistent and logical (non-surprising) >> way to merge the 2 paths in the 2 uris... especially >> when you consider that ap_runtime_dir_relative() >> should really be applied as well. >> >> S >> >> I'm proposing that we simply drop the "sock:..." >> part and use 2 things as the "this is a UDS" >> trigger: >> >> 1. hostname is 'localhost' >> 2. the '|' is the last char of the URL >> >> eg: >> >>ajp://localhost/./rel/dir/foo.sock| >>http://localhost/var/tmp/s.sock| >> >> Comments? >
RE: uds support
> -Original Message- > From: Jim Jagielski > Sent: Montag, 14. Oktober 2013 15:45 > To: dev@httpd.apache.org > Subject: Re: uds support > > Which one? > > sock://var/run/server.sock|http://localhost/foo/bar > > or > > http://localhost/foo/bar|sock:/var/run.s.sock > > I guess we could say that the path info for the "segment" that > provides the communication scheme (http://localhost/... above), > if any, is ignored. > > eg: > > http://localhost/|sock:./rel/dir/s.sock > ajp://localhost/ignored/path|sock:/var/run/a.sock I like the above ones most. Regards Rüdiger
Re: uds support
On Oct 14, 2013, at 10:09 AM, Plüm, Rüdiger, Vodafone Group wrote: > > >> -Original Message- >> From: Jim Jagielski >> Sent: Montag, 14. Oktober 2013 15:45 >> To: dev@httpd.apache.org >> Subject: Re: uds support >> >> Which one? >> >> sock://var/run/server.sock|http://localhost/foo/bar >> >> or >> >> http://localhost/foo/bar|sock:/var/run.s.sock >> >> I guess we could say that the path info for the "segment" that >> provides the communication scheme (http://localhost/... above), >> if any, is ignored. >> >> eg: >> >> http://localhost/|sock:./rel/dir/s.sock >> ajp://localhost/ignored/path|sock:/var/run/a.sock > > I like the above ones most. > Any comments regarding using file: vs. sock: ??
Re: uds support
On Mon, 14 Oct 2013, Jim Jagielski wrote: > On Oct 14, 2013, at 10:09 AM, Plüm, Rüdiger, Vodafone Group > wrote: > >> Which one? > >> > >>sock://var/run/server.sock|http://localhost/foo/bar > >> > >> or > >> > >>http://localhost/foo/bar|sock:/var/run.s.sock > >> > >> I guess we could say that the path info for the "segment" that > >> provides the communication scheme (http://localhost/... above), > >> if any, is ignored. > >> > >> eg: > >> > >>http://localhost/|sock:./rel/dir/s.sock > >>ajp://localhost/ignored/path|sock:/var/run/a.sock > > > > I like the above ones most. IMO it would be better to have the sock: at the start, so that it is immediately obvious. Imagine that you'd had to scan a > 80 char URL with several url parameters for the "|", that's annoying and error-prone. Alternatively, use a hostname that really stands out, like _unix_ or _socket_. For the scheme I would actually prefer unix:, because that is what other programs use (X, socat), and there are a lot more different socket types than unix. If not that, I would still prefer sock: over file:, because it is IMHO more correct.
Re: uds support
I see a suggestion to: 1. s/sock:/unix:/ 2. Reorg as unix:/whatever|http://localhost/ any other comments? I'd like to nail this down...
Re: uds support
I went ahead and made an "exec" decision to baseline unix:/path/to/sock.sock|http: as canon. trunk now does this.
Re: uds support
On 15 Oct 2013, at 7:01 PM, Jim Jagielski wrote: > I went ahead and made an "exec" decision to baseline > > unix:/path/to/sock.sock|http: > > as canon. trunk now does this. Can we further define it that "/path/to/sock.sock" is urlencoded? The | character makes me twitch, but I don't have a better suggestion. :( Regards, Graham --
Re: uds support
On Oct 15, 2013, at 3:33 PM, Graham Leggett wrote: > On 15 Oct 2013, at 7:01 PM, Jim Jagielski wrote: > >> I went ahead and made an "exec" decision to baseline >> >> unix:/path/to/sock.sock|http: >> >> as canon. trunk now does this. > > Can we further define it that "/path/to/sock.sock" is urlencoded? It's a file-system path so... :) > > The | character makes me twitch, but I don't have a better suggestion. :( > I hear ya. Yeah, same here. The only other one I could come up with is '^'. We just need a delim that couldn't be considered part of a valid URI (even though the code is smart enough to ignore it if what follows doesn't look like a URL).
Re: uds support
On Tue, Oct 15, 2013 at 1:01 PM, Jim Jagielski wrote: > > I went ahead and made an "exec" decision to baseline > > unix:/path/to/sock.sock|http: > > as canon. trunk now does this. Jim, thanks for working on this. With this latest approach how is the URI path specified? For example, with the original patch which relied on the URL encoded slashes we could have: ProxyPass fcgi://socket=%2ftmp%2fphp-fpm.sock/local/htdocs/ How would that look now (specifically the /local/htdocs portion)? -- Blaise
Re: uds support
On Oct 15, 2013, at 4:57 PM, Blaise Tarr wrote: > On Tue, Oct 15, 2013 at 1:01 PM, Jim Jagielski wrote: > > > > I went ahead and made an "exec" decision to baseline > > > > unix:/path/to/sock.sock|http: > > > > as canon. trunk now does this. > > Jim, thanks for working on this. With this latest approach how is the URI > path specified? For example, with the original patch which relied on the URL > encoded slashes we could have: > > ProxyPass fcgi://socket=%2ftmp%2fphp-fpm.sock/local/htdocs/ > > How would that look now (specifically the /local/htdocs portion)? > Currently, the path of the http: (or whatever) path is ignored; the next step is to add that in.
Re: uds support
One thing about "lumping" both the UDS path *and* the actual URL into the name field is that it really limits the size of both, such that, long term, I think it will come back and bite us. Since last night I've been working on a plan to simply create a new field for the path, which gives us a lot more breathing room and places less restrictions on URL and pathname length.
Re: uds support
On 10/16/2013 6:43 AM, Jim Jagielski wrote: > One thing about "lumping" both the UDS path *and* the > actual URL into the name field is that it really limits > the size of both, such that, long term, I think it will > come back and bite us. Since last night I've been working > on a plan to simply create a new field for the path, > which gives us a lot more breathing room and places > less restrictions on URL and pathname length. Been MIA for the past few days and I'm confused on what the final direction is - can you clarify? FWIW, I rather liked this idea: On Oct 11, 2013, at 12:24 PM, Jim Jagielski wrote: > Committed in r1531340 the above is implemented... kinda. > I instead went with > > http://localhost/foo/bar|sock:/var/run.s.sock > > which worked out just a bit cleaner... ... because as a server administrator, it's fairly clear what's going on. Can you elaborate on what the challenges were with merging the two paths? Why merge them at all? It seems logical that everything after the pipe is used to open the socket and everything prior is treated as it has always been and never shall the two mix... or am I over simplifying things? IMO, the syntax you suggested on the 11th also allows for a bit of "futureproofing" in that "sock:" can be replaced with all kinds of things down the road. Maybe some day I'll have an ethernet cord plugged into my ear and it'll become http://localhost/memory|brain:/pub/wetware.sock :-) Also Per some other discussion, it seems like using localhost as HTTP host is too restrictive. I'd hate to think that a UDS backend can't implement its own concept of name-based vhosts behind Apache because localhost is forced as the Host header. -- Daniel Ruggeri
UDS support for mod_rewrite
FWIW, I'm looking into adding UDS support for mod_rewrite (et.al.) by making the generic default reverse proxy worker UDS aware.
UDS support in mod_proxy (trunk)
UDS support in mod_proxy is at a stage for some serious testing... Although the chances of it being viable for 2.4.7 is small, I think it's good possibility for 2.4.8.
Re: UDS support for mod_rewrite
Cool :).
As a workaround for that limitation I was using a "hack" (in case someone
finds it useful):
ProxyPass /mybackend-fpm-proxy !
ProxyPass /mybackend-fpm-proxy unix:/path/to/www.sock|fcgi://mybackend-fpm/
...
RewriteRule ^(.*\.php(/.*)?)$ fcgi://mybackend-fpm/%{REQUEST_FILENAME} [P,L]
...
As the workers are find by url, I can omit the socket it the rewrite, but
I'm forced to define them using a ProxyPass. As I'm not interested in
mapping an url to the proxy, I disable it (with the ! part), which looks
really ugly :).
Do you think that approach is safe or is it likely to break at some point?
(relaying on the workers being located by url in that way, without having
to provide the socket in the rewrite)
Best regards,
Juanjo.
2014/1/21 Jim Jagielski
> FWIW, I'm looking into adding UDS support for mod_rewrite (et.al.)
> by making the generic default reverse proxy worker UDS aware.
>
Re: UDS support for mod_rewrite
Just added as http://svn.apache.org/r1560367 is my initial effort. It requires that rewrite rules have [P,NE] to avoid escaping the '|' in the path, but other than that, it works as needed. I haven't stressed it though. On Jan 21, 2014, at 4:38 PM, Jim Jagielski wrote: > FWIW, I'm looking into adding UDS support for mod_rewrite (et.al.) > by making the generic default reverse proxy worker UDS aware. >
Re: UDS support for mod_rewrite
Instead of using ProxyPass you can also use a block to force the
creation of a worker.
Regards
Rüdiger
Juan José Medina Godoy wrote:
> Cool :).
>
> As a workaround for that limitation I was using a "hack" (in case someone
> finds it useful):
>
> ProxyPass /mybackend-fpm-proxy !
> ProxyPass /mybackend-fpm-proxy unix:/path/to/www.sock|fcgi://mybackend-fpm/
> ...
> RewriteRule ^(.*\.php(/.*)?)$ fcgi://mybackend-fpm/%{REQUEST_FILENAME} [P,L]
> ...
>
> As the workers are find by url, I can omit the socket it the rewrite, but I'm
> forced to define them using a ProxyPass.
> As I'm not interested in mapping an url to the proxy, I disable it (with the
> ! part), which looks really ugly :).
>
> Do you think that approach is safe or is it likely to break at some point?
> (relaying on the workers being located by url
> in that way, without having to provide the socket in the rewrite)
>
> Best regards,
>
> Juanjo.
>
>
>
> 2014/1/21 Jim Jagielski mailto:j...@jagunet.com>>
>
> FWIW, I'm looking into adding UDS support for mod_rewrite (et.al
> <http://et.al>.)
> by making the generic default reverse proxy worker UDS aware.
>
>
Re: UDS support for mod_rewrite
Yeppers... The key thing to remember that it was only
pre-existing workers (ie: those defined) that could
be associated with UDS, and so if you could "trick"
mod_rewrite (or anyone else) to use that worker, you
were golden.
The problem was the mod_rewrite, in general, would use
the generic reverse proxy worker, and so I needed to
add code that would see if rewrite had forced a proxy:
and then adjust that generic worker accordingly.
Your "hack" has the additional benefit is being
a pooled connection and not a one-shot, and therefore
will have better performance. But that isn't related
to UDS at all.
On Jan 22, 2014, at 6:48 AM, Juan José Medina Godoy
wrote:
> Cool :).
>
> As a workaround for that limitation I was using a "hack" (in case someone
> finds it useful):
>
> ProxyPass /mybackend-fpm-proxy !
> ProxyPass /mybackend-fpm-proxy unix:/path/to/www.sock|fcgi://mybackend-fpm/
> ...
> RewriteRule ^(.*\.php(/.*)?)$ fcgi://mybackend-fpm/%{REQUEST_FILENAME} [P,L]
> ...
>
> As the workers are find by url, I can omit the socket it the rewrite, but I'm
> forced to define them using a ProxyPass. As I'm not interested in mapping an
> url to the proxy, I disable it (with the ! part), which looks really ugly :).
>
> Do you think that approach is safe or is it likely to break at some point?
> (relaying on the workers being located by url in that way, without having to
> provide the socket in the rewrite)
>
> Best regards,
>
> Juanjo.
>
>
>
> 2014/1/21 Jim Jagielski
> FWIW, I'm looking into adding UDS support for mod_rewrite (et.al.)
> by making the generic default reverse proxy worker UDS aware.
>
Re: UDS support for mod_rewrite
On 1/22/2014 5:48 AM, Juan José Medina Godoy wrote: > Do you think that approach is safe or is it likely to break at some > point? (relaying on the workers being located by url in that way, > without having to provide the socket in the rewrite) Seems safe... and quite clever, actually. -- Daniel Ruggeri
Re: UDS support for mod_rewrite
>Your "hack" has the additional benefit is being >a pooled connection and not a one-shot, and therefore >will have better performance. But that isn't related >to UDS at all. Well, it is related to UDS in the sense of being my solution to make my rewrites end up serving content obtained through a Unix socket :). I initially had the old version of the UDS patch working with mod_rewrite (using the default forward proxy worker) but it broke with newer versions of the patch so I figured out that way of tricking mod_rewrite. Regarding using a section to define the workers, I see the code that should be defining it but I'm not able to make it work. I will investigate it a little further, thanks! Best regards, Juanjo. 2014/1/22 Daniel Ruggeri > On 1/22/2014 5:48 AM, Juan José Medina Godoy wrote: > > Do you think that approach is safe or is it likely to break at some > > point? (relaying on the workers being located by url in that way, > > without having to provide the socket in the rewrite) > > Seems safe... and quite clever, actually. > > -- > Daniel Ruggeri > > -- I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near Tannhauser Gate. All those moments will be lost in time like tears in rain. Time to die.
Re: UDS support for mod_rewrite
Just a las quick comment about using a section to define the proxy. I could not make it work using the below snippet: Digging into the code, I realized the worker was only created if more arguments were provided (which is not mentioned to be possible in the docs, or I could not find it): Then the worker is created and I can remove my extra "ProxyPass" directives. Is it intended to only create the worker if we need to configure its settings? It makes sense but it would be a good improvement to make the worker to be always created if it does not exists, regardless of if some more settings are provided. Sorry about the offtopic and thanks a lot to Rüdiger for the hint! 2014/1/22 ryo takatsuki > >Your "hack" has the additional benefit is being > >a pooled connection and not a one-shot, and therefore > >will have better performance. But that isn't related > >to UDS at all. > > Well, it is related to UDS in the sense of being my solution to make my > rewrites end up serving content obtained through a Unix socket :). > > I initially had the old version of the UDS patch working with mod_rewrite > (using the default forward proxy worker) but it broke with newer versions > of the patch so I figured out that way of tricking mod_rewrite. > > Regarding using a section to define the workers, I see the code > that should be defining it but I'm not able to make it work. I will > investigate it a little further, thanks! > > Best regards, > > Juanjo. > > > 2014/1/22 Daniel Ruggeri > >> On 1/22/2014 5:48 AM, Juan José Medina Godoy wrote: >> > Do you think that approach is safe or is it likely to break at some >> > point? (relaying on the workers being located by url in that way, >> > without having to provide the socket in the rewrite) >> >> Seems safe... and quite clever, actually. >> >> -- >> Daniel Ruggeri >> >> > > > -- > I've seen things you people wouldn't believe. > Attack ships on fire off the shoulder of Orion. > I watched C-beams glitter in the dark near Tannhauser Gate. > All those moments will be lost in time like tears in rain. > Time to die. > -- I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near Tannhauser Gate. All those moments will be lost in time like tears in rain. Time to die.
AW: UDS support for mod_rewrite
Yes, forgot to mention this. You need to set at least one option get it created. Regards Rüdiger Von: ryo takatsuki [mailto:ryotakats...@gmail.com] Gesendet: Mittwoch, 22. Januar 2014 19:07 An: dev@httpd.apache.org Betreff: Re: UDS support for mod_rewrite Just a las quick comment about using a section to define the proxy. I could not make it work using the below snippet: Digging into the code, I realized the worker was only created if more arguments were provided (which is not mentioned to be possible in the docs, or I could not find it): Then the worker is created and I can remove my extra "ProxyPass" directives. Is it intended to only create the worker if we need to configure its settings? It makes sense but it would be a good improvement to make the worker to be always created if it does not exists, regardless of if some more settings are provided. Sorry about the offtopic and thanks a lot to Rüdiger for the hint! 2014/1/22 ryo takatsuki mailto:ryotakats...@gmail.com>> >Your "hack" has the additional benefit is being >a pooled connection and not a one-shot, and therefore >will have better performance. But that isn't related >to UDS at all. Well, it is related to UDS in the sense of being my solution to make my rewrites end up serving content obtained through a Unix socket :). I initially had the old version of the UDS patch working with mod_rewrite (using the default forward proxy worker) but it broke with newer versions of the patch so I figured out that way of tricking mod_rewrite. Regarding using a section to define the workers, I see the code that should be defining it but I'm not able to make it work. I will investigate it a little further, thanks! Best regards, Juanjo. 2014/1/22 Daniel Ruggeri mailto:drugg...@primary.net>> On 1/22/2014 5:48 AM, Juan José Medina Godoy wrote: > Do you think that approach is safe or is it likely to break at some > point? (relaying on the workers being located by url in that way, > without having to provide the socket in the rewrite) Seems safe... and quite clever, actually. -- Daniel Ruggeri -- I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near Tannhauser Gate. All those moments will be lost in time like tears in rain. Time to die. -- I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near Tannhauser Gate. All those moments will be lost in time like tears in rain. Time to die.
Re: UDS support for mod_rewrite
Hi,
I am checking the new patch (thanks again!) and I'm finding some issues
trying to connect to PHP-FPM using the socket. The problem seems to be that
the filename sent to the proxy is defined as "fcgi://localhost/..." where
it usually is "proxy:fcgi://localhost/..." (being the last form the one PHP
expects).
It seems the "proxy:" prefix is stripped when the socket is extracted. The
below patch fixes it but I'm not sure is the best solution:
diff --git a/modules/proxy/proxy_util.c b/modules/proxy/proxy_util.c
index fb6426b..909c384 100644
--- a/modules/proxy/proxy_util.c
+++ b/modules/proxy/proxy_util.c
@@ -1959,8 +1959,8 @@ PROXY_DECLARE(int) ap_proxy_pre_request(proxy_worker
**worker,
if (rv == APR_SUCCESS) {
char *sockpath = ap_runtime_dir_relative(r->pool,
urisock.path);
apr_table_setn(r->notes, "uds_path", sockpath);
-r->filename = ptr+1;/* so we get the scheme
for the uds */
-*url = apr_pstrdup(r->pool, r->filename);
+r->filename = apr_pstrcat(r->pool, "proxy:",ptr+1,
NULL);
+*url = apr_pstrdup(r->pool, ptr+1);
ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
"*: rewrite of url due to UDS: %s",
*url);
}
Regards,
Juanjo.
2014-01-22 Plüm, Rüdiger, Vodafone Group
> Yes, forgot to mention this. You need to set at least one option get it
> created.
>
>
>
> Regards
>
>
>
> Rüdiger
>
>
>
> *Von:* ryo takatsuki [mailto:ryotakats...@gmail.com]
> *Gesendet:* Mittwoch, 22. Januar 2014 19:07
> *An:* dev@httpd.apache.org
> *Betreff:* Re: UDS support for mod_rewrite
>
>
>
> Just a las quick comment about using a section to define the
> proxy. I could not make it work using the below snippet:
>
>
>
>
>
>
>
>
>
> Digging into the code, I realized the worker was only created if more
> arguments were provided (which is not mentioned to be possible in the docs,
> or I could not find it):
>
>
>
>
>
>
>
>
>
> Then the worker is created and I can remove my extra "ProxyPass"
> directives. Is it intended to only create the worker if we need to
> configure its settings?
>
>
>
> It makes sense but it would be a good improvement to make the worker to be
> always created if it does not exists, regardless of if some more settings
> are provided.
>
>
>
> Sorry about the offtopic and thanks a lot to Rüdiger for the hint!
>
>
>
> 2014/1/22 ryo takatsuki
>
> >Your "hack" has the additional benefit is being
>
> >a pooled connection and not a one-shot, and therefore
>
> >will have better performance. But that isn't related
>
> >to UDS at all.
>
>
>
> Well, it is related to UDS in the sense of being my solution to make my
> rewrites end up serving content obtained through a Unix socket :).
>
>
>
> I initially had the old version of the UDS patch working with mod_rewrite
> (using the default forward proxy worker) but it broke with newer versions
> of the patch so I figured out that way of tricking mod_rewrite.
>
>
>
> Regarding using a section to define the workers, I see the code
> that should be defining it but I'm not able to make it work. I will
> investigate it a little further, thanks!
>
>
>
> Best regards,
>
>
>
> Juanjo.
>
>
>
> 2014/1/22 Daniel Ruggeri
>
> On 1/22/2014 5:48 AM, Juan José Medina Godoy wrote:
> > Do you think that approach is safe or is it likely to break at some
> > point? (relaying on the workers being located by url in that way,
> > without having to provide the socket in the rewrite)
>
> Seems safe... and quite clever, actually.
>
> --
> Daniel Ruggeri
>
>
>
>
>
> --
> I've seen things you people wouldn't believe.
> Attack ships on fire off the shoulder of Orion.
> I watched C-beams glitter in the dark near Tannhauser Gate.
> All those moments will be lost in time like tears in rain.
> Time to die.
>
>
>
>
>
> --
> I've seen things you people wouldn't believe.
> Attack ships on fire off the shoulder of Orion.
> I watched C-beams glitter in the dark near Tannhauser Gate.
> All those moments will be lost in time like tears in rain.
> Time to die.
>
--
I've seen things you people wouldn't believe.
Attack ships on fire off the shoulder of Orion.
I watched C-beams glitter in the dark near Tannhauser Gate.
All those moments will be lost in time like tears in rain.
Time to die.
Re: UDS support for mod_rewrite
proxy:fcgi is what mod_rewrite send and the patch
takes specific action to remove that 'proxy:' part.
Are you saying that PHP-FPM requires that the r->filename
AND the URL have that prepended? That seems weird
and wrong to me...
On Jan 26, 2014, at 10:49 AM, ryo takatsuki wrote:
> Hi,
>
> I am checking the new patch (thanks again!) and I'm finding some issues
> trying to connect to PHP-FPM using the socket. The problem seems to be that
> the filename sent to the proxy is defined as "fcgi://localhost/..." where it
> usually is "proxy:fcgi://localhost/..." (being the last form the one PHP
> expects).
>
> It seems the "proxy:" prefix is stripped when the socket is extracted. The
> below patch fixes it but I'm not sure is the best solution:
>
> diff --git a/modules/proxy/proxy_util.c b/modules/proxy/proxy_util.c
> index fb6426b..909c384 100644
> --- a/modules/proxy/proxy_util.c
> +++ b/modules/proxy/proxy_util.c
> @@ -1959,8 +1959,8 @@ PROXY_DECLARE(int) ap_proxy_pre_request(proxy_worker
> **worker,
> if (rv == APR_SUCCESS) {
> char *sockpath = ap_runtime_dir_relative(r->pool,
> urisock.path);
> apr_table_setn(r->notes, "uds_path", sockpath);
> -r->filename = ptr+1;/* so we get the scheme for
> the uds */
> -*url = apr_pstrdup(r->pool, r->filename);
> +r->filename = apr_pstrcat(r->pool, "proxy:",ptr+1,
> NULL);
> +*url = apr_pstrdup(r->pool, ptr+1);
> ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
>"*: rewrite of url due to UDS: %s",
> *url);
> }
>
>
> Regards,
>
> Juanjo.
>
>
> 2014-01-22 Plüm, Rüdiger, Vodafone Group
> Yes, forgot to mention this. You need to set at least one option get it
> created.
>
>
>
> Regards
>
>
>
> Rüdiger
>
>
>
> Von: ryo takatsuki [mailto:ryotakats...@gmail.com]
> Gesendet: Mittwoch, 22. Januar 2014 19:07
> An: dev@httpd.apache.org
> Betreff: Re: UDS support for mod_rewrite
>
>
>
> Just a las quick comment about using a section to define the proxy. I
> could not make it work using the below snippet:
>
>
>
>
>
>
>
>
>
> Digging into the code, I realized the worker was only created if more
> arguments were provided (which is not mentioned to be possible in the docs,
> or I could not find it):
>
>
>
>
>
>
>
>
>
> Then the worker is created and I can remove my extra "ProxyPass" directives.
> Is it intended to only create the worker if we need to configure its settings?
>
>
>
> It makes sense but it would be a good improvement to make the worker to be
> always created if it does not exists, regardless of if some more settings are
> provided.
>
>
>
> Sorry about the offtopic and thanks a lot to Rüdiger for the hint!
>
>
>
> 2014/1/22 ryo takatsuki
>
> >Your "hack" has the additional benefit is being
>
> >a pooled connection and not a one-shot, and therefore
>
> >will have better performance. But that isn't related
>
> >to UDS at all.
>
>
>
> Well, it is related to UDS in the sense of being my solution to make my
> rewrites end up serving content obtained through a Unix socket :).
>
>
>
> I initially had the old version of the UDS patch working with mod_rewrite
> (using the default forward proxy worker) but it broke with newer versions of
> the patch so I figured out that way of tricking mod_rewrite.
>
>
>
> Regarding using a section to define the workers, I see the code that
> should be defining it but I'm not able to make it work. I will investigate it
> a little further, thanks!
>
>
>
> Best regards,
>
>
>
> Juanjo.
>
>
>
> 2014/1/22 Daniel Ruggeri
>
> On 1/22/2014 5:48 AM, Juan José Medina Godoy wrote:
> > Do you think that approach is safe or is it likely to break at some
> > point? (relaying on the workers being located by url in that way,
> > without having to provide the socket in the rewrite)
>
> Seems safe... and quite clever, actually.
>
> --
> Daniel Ruggeri
>
>
>
>
>
>
> --
> I've seen things you people wouldn't believe.
> Attack ships on fire off the shoulder of Orion.
> I watched C-beams glitter in the dark near Tannhauser Gate.
> All those moments will be lost in time like tears in rain.
> Time to die.
>
>
>
>
>
>
> --
> I've seen things you people wouldn't believe.
> Attack ships on fire off the shoulder of Orion.
> I watched C-beams glitter in the dark near Tannhauser Gate.
> All those moments will be lost in time like tears in rain.
> Time to die.
>
>
>
>
> --
> I've seen things you people wouldn't believe.
> Attack ships on fire off the shoulder of Orion.
> I watched C-beams glitter in the dark near Tannhauser Gate.
> All those moments will be lost in time like tears in rain.
> Time to die.
Re: UDS support for mod_rewrite
prefix is stripped when the socket is extracted.
> The below patch fixes it but I'm not sure is the best solution:
> >
> > diff --git a/modules/proxy/proxy_util.c b/modules/proxy/proxy_util.c
> > index fb6426b..909c384 100644
> > --- a/modules/proxy/proxy_util.c
> > +++ b/modules/proxy/proxy_util.c
> > @@ -1959,8 +1959,8 @@ PROXY_DECLARE(int)
> ap_proxy_pre_request(proxy_worker **worker,
> > if (rv == APR_SUCCESS) {
> > char *sockpath =
> ap_runtime_dir_relative(r->pool, urisock.path);
> > apr_table_setn(r->notes, "uds_path", sockpath);
> > -r->filename = ptr+1;/* so we get the scheme
> for the uds */
> > -*url = apr_pstrdup(r->pool, r->filename);
> > +r->filename = apr_pstrcat(r->pool,
> "proxy:",ptr+1, NULL);
> > +*url = apr_pstrdup(r->pool, ptr+1);
> > ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
> > "*: rewrite of url due to UDS:
> %s", *url);
> > }
> >
> >
> > Regards,
> >
> > Juanjo.
> >
> >
> > 2014-01-22 Plüm, Rüdiger, Vodafone Group
> > Yes, forgot to mention this. You need to set at least one option get it
> created.
> >
> >
> >
> > Regards
> >
> >
> >
> > Rüdiger
> >
> >
> >
> > Von: ryo takatsuki [mailto:ryotakats...@gmail.com]
> > Gesendet: Mittwoch, 22. Januar 2014 19:07
> > An: dev@httpd.apache.org
> > Betreff: Re: UDS support for mod_rewrite
> >
> >
> >
> > Just a las quick comment about using a section to define the
> proxy. I could not make it work using the below snippet:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Digging into the code, I realized the worker was only created if more
> arguments were provided (which is not mentioned to be possible in the docs,
> or I could not find it):
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Then the worker is created and I can remove my extra "ProxyPass"
> directives. Is it intended to only create the worker if we need to
> configure its settings?
> >
> >
> >
> > It makes sense but it would be a good improvement to make the worker to
> be always created if it does not exists, regardless of if some more
> settings are provided.
> >
> >
> >
> > Sorry about the offtopic and thanks a lot to Rüdiger for the hint!
> >
> >
> >
> > 2014/1/22 ryo takatsuki
> >
> > >Your "hack" has the additional benefit is being
> >
> > >a pooled connection and not a one-shot, and therefore
> >
> > >will have better performance. But that isn't related
> >
> > >to UDS at all.
> >
> >
> >
> > Well, it is related to UDS in the sense of being my solution to make my
> rewrites end up serving content obtained through a Unix socket :).
> >
> >
> >
> > I initially had the old version of the UDS patch working with
> mod_rewrite (using the default forward proxy worker) but it broke with
> newer versions of the patch so I figured out that way of tricking
> mod_rewrite.
> >
> >
> >
> > Regarding using a section to define the workers, I see the code
> that should be defining it but I'm not able to make it work. I will
> investigate it a little further, thanks!
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Juanjo.
> >
> >
> >
> > 2014/1/22 Daniel Ruggeri
> >
> > On 1/22/2014 5:48 AM, Juan José Medina Godoy wrote:
> > > Do you think that approach is safe or is it likely to break at some
> > > point? (relaying on the workers being located by url in that way,
> > > without having to provide the socket in the rewrite)
> >
> > Seems safe... and quite clever, actually.
> >
> > --
> > Daniel Ruggeri
> >
> >
> >
> >
> >
> >
> > --
> > I've seen things you people wouldn't believe.
> > Attack ships on fire off the shoulder of Orion.
> > I watched C-beams glitter in the dark near Tannhauser Gate.
> > All those moments will be lost in time like tears in rain.
> > Time to die.
> >
> >
> >
> >
> >
> >
> > --
> > I've seen things you people wouldn't believe.
> > Attack ships on fire off the shoulder of Orion.
> > I watched C-beams glitter in the dark near Tannhauser Gate.
> > All those moments will be lost in time like tears in rain.
> > Time to die.
> >
> >
> >
> >
> > --
> > I've seen things you people wouldn't believe.
> > Attack ships on fire off the shoulder of Orion.
> > I watched C-beams glitter in the dark near Tannhauser Gate.
> > All those moments will be lost in time like tears in rain.
> > Time to die.
>
>
--
I've seen things you people wouldn't believe.
Attack ships on fire off the shoulder of Orion.
I watched C-beams glitter in the dark near Tannhauser Gate.
All those moments will be lost in time like tears in rain.
Time to die.
Re: UDS support for mod_rewrite
On Jan 27, 2014, at 4:20 AM, ryo takatsuki wrote: > Hi, > > First of all, sorry for the trouble if this ends up being a > misconfiguration/misunderstanding of the code on my side :) > > >Are you saying that PHP-FPM requires that the r->filename > >AND the URL have that prepended? That seems weird > >and wrong to me... > > Yep, but only the filename. Oh. OK, that makes more sense. Thx.
Re: UDS support for mod_rewrite
Fixed in r1561660 On Jan 27, 2014, at 7:34 AM, Jim Jagielski wrote: > > On Jan 27, 2014, at 4:20 AM, ryo takatsuki wrote: > >> Hi, >> >> First of all, sorry for the trouble if this ends up being a >> misconfiguration/misunderstanding of the code on my side :) >> >>> Are you saying that PHP-FPM requires that the r->filename >>> AND the URL have that prepended? That seems weird >>> and wrong to me... >> >> Yep, but only the filename. > > Oh. OK, that makes more sense. Thx. >
Re: UDS support for mod_rewrite
It is working perfectly now. Thanks! 2014-01-27 Jim Jagielski > Fixed in r1561660 > On Jan 27, 2014, at 7:34 AM, Jim Jagielski wrote: > > > > > On Jan 27, 2014, at 4:20 AM, ryo takatsuki > wrote: > > > >> Hi, > >> > >> First of all, sorry for the trouble if this ends up being a > misconfiguration/misunderstanding of the code on my side :) > >> > >>> Are you saying that PHP-FPM requires that the r->filename > >>> AND the URL have that prepended? That seems weird > >>> and wrong to me... > >> > >> Yep, but only the filename. > > > > Oh. OK, that makes more sense. Thx. > > > > -- I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near Tannhauser Gate. All those moments will be lost in time like tears in rain. Time to die.
Re: UDS support for mod_rewrite
Hi all, Quick question related to UDS and mod_rewrite. I see the UDS patches have been backported to 2.4.8 but the fix for making mod_rewrite and UDS was not included. Was that intended? I'm referring to r1560367 Best regards, Juanjo. 2014-01-27 15:12 GMT+01:00 ryo takatsuki : > It is working perfectly now. Thanks! > > > 2014-01-27 Jim Jagielski > >> Fixed in r1561660 >> On Jan 27, 2014, at 7:34 AM, Jim Jagielski wrote: >> >> > >> > On Jan 27, 2014, at 4:20 AM, ryo takatsuki >> > wrote: >> > >> >> Hi, >> >> >> >> First of all, sorry for the trouble if this ends up being a >> >> misconfiguration/misunderstanding of the code on my side :) >> >> >> >>> Are you saying that PHP-FPM requires that the r->filename >> >>> AND the URL have that prepended? That seems weird >> >>> and wrong to me... >> >> >> >> Yep, but only the filename. >> > >> > Oh. OK, that makes more sense. Thx. >> > >> > > > > -- > I've seen things you people wouldn't believe. > Attack ships on fire off the shoulder of Orion. > I watched C-beams glitter in the dark near Tannhauser Gate. > All those moments will be lost in time like tears in rain. > Time to die. -- I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near Tannhauser Gate. All those moments will be lost in time like tears in rain. Time to die.
Re: UDS support for mod_rewrite
Hi Juanjo, the patch with mod_rewrite is still being worked on (see https://www.mail-archive.com/dev@httpd.apache.org/msg59276.html), precisely because it is not possible, yet, to refer to a defined backend ( declared, as you did in this thread) with a RewriteRule. The default proxy only is used, for now, hence connections can't be configured (for reuse, timeouts...). I guess this will be part of 2.4.9 (at best). Regards, Yann. On Mon, Mar 10, 2014 at 12:41 PM, ryo takatsuki wrote: > Hi all, > > Quick question related to UDS and mod_rewrite. I see the UDS patches > have been backported to 2.4.8 but the fix for making mod_rewrite and > UDS was not included. Was that intended? I'm referring to r1560367 > > Best regards, > > Juanjo. > > 2014-01-27 15:12 GMT+01:00 ryo takatsuki : >> It is working perfectly now. Thanks! >> >> >> 2014-01-27 Jim Jagielski >> >>> Fixed in r1561660 >>> On Jan 27, 2014, at 7:34 AM, Jim Jagielski wrote: >>> >>> > >>> > On Jan 27, 2014, at 4:20 AM, ryo takatsuki >>> > wrote: >>> > >>> >> Hi, >>> >> >>> >> First of all, sorry for the trouble if this ends up being a >>> >> misconfiguration/misunderstanding of the code on my side :) >>> >> >>> >>> Are you saying that PHP-FPM requires that the r->filename >>> >>> AND the URL have that prepended? That seems weird >>> >>> and wrong to me... >>> >> >>> >> Yep, but only the filename. >>> > >>> > Oh. OK, that makes more sense. Thx. >>> > >>> >> >> >> >> -- >> I've seen things you people wouldn't believe. >> Attack ships on fire off the shoulder of Orion. >> I watched C-beams glitter in the dark near Tannhauser Gate. >> All those moments will be lost in time like tears in rain. >> Time to die. > > > > -- > I've seen things you people wouldn't believe. > Attack ships on fire off the shoulder of Orion. > I watched C-beams glitter in the dark near Tannhauser Gate. > All those moments will be lost in time like tears in rain. > Time to die.
Re: UDS support for mod_rewrite
Thanks for the clarification! 2014-03-10 13:05 GMT+01:00 Yann Ylavic : > Hi Juanjo, > > the patch with mod_rewrite is still being worked on (see > https://www.mail-archive.com/dev@httpd.apache.org/msg59276.html), > precisely because it is not possible, yet, to refer to a defined > backend ( declared, as you did in this thread) with a > RewriteRule. > > The default proxy only is used, for now, hence connections can't be > configured (for reuse, timeouts...). > > I guess this will be part of 2.4.9 (at best). > > Regards, > Yann. > > > On Mon, Mar 10, 2014 at 12:41 PM, ryo takatsuki > wrote: >> Hi all, >> >> Quick question related to UDS and mod_rewrite. I see the UDS patches >> have been backported to 2.4.8 but the fix for making mod_rewrite and >> UDS was not included. Was that intended? I'm referring to r1560367 >> >> Best regards, >> >> Juanjo. >> >> 2014-01-27 15:12 GMT+01:00 ryo takatsuki : >>> It is working perfectly now. Thanks! >>> >>> >>> 2014-01-27 Jim Jagielski >>> Fixed in r1561660 On Jan 27, 2014, at 7:34 AM, Jim Jagielski wrote: > > On Jan 27, 2014, at 4:20 AM, ryo takatsuki > wrote: > >> Hi, >> >> First of all, sorry for the trouble if this ends up being a >> misconfiguration/misunderstanding of the code on my side :) >> >>> Are you saying that PHP-FPM requires that the r->filename >>> AND the URL have that prepended? That seems weird >>> and wrong to me... >> >> Yep, but only the filename. > > Oh. OK, that makes more sense. Thx. > >>> >>> >>> >>> -- >>> I've seen things you people wouldn't believe. >>> Attack ships on fire off the shoulder of Orion. >>> I watched C-beams glitter in the dark near Tannhauser Gate. >>> All those moments will be lost in time like tears in rain. >>> Time to die. >> >> >> >> -- >> I've seen things you people wouldn't believe. >> Attack ships on fire off the shoulder of Orion. >> I watched C-beams glitter in the dark near Tannhauser Gate. >> All those moments will be lost in time like tears in rain. >> Time to die. -- I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near Tannhauser Gate. All those moments will be lost in time like tears in rain. Time to die.
Re: UDS support in mod_proxy (trunk)
On Fri, Oct 18, 2013 at 9:30 AM, Jim Jagielski wrote: > > UDS support in mod_proxy is at a stage for some serious > testing... Tested with httpd SVN trunk r1534292 plus apr SVN trunk r1534314. First I verified that mod_proxy_fcgi works as expected with TCP sockets using this config: # PHP-FPM listening on localhost port 9070 # docroot is /var/opt/content-8003/ ProxyPass fcgi://localhost:9070/var/opt/content-8003/ and of course that worked. Then I tried with UDS using this config: # PHP-FPM listening on UDS /var/opt/php-fpm/s8071/run/php-fpm.sock # docroot is /var/opt/content-8003/ ProxyPass unix:/var/opt/php-fpm/s8071/run/php-fpm.sock|fcgi:///var/opt/content-8003/ but got this error: [Mon Oct 21 12:43:15.042260 2013] [proxy:warn] [pid 6575:tid 1157982528] [client 10.17.35.38:56195] AH01144: No protocol handler was valid for the URL /info.php. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. I haven't yet had a chance to investigate further. -- Blaise
