You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2013/08/23 21:05:10 UTC
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <da...@cbsi.com> 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 <ji...@jagunet.com> wrote:
>
> On Aug 27, 2013, at 7:09 PM, Daniel Ruggeri <DR...@primary.net> 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
Posted by Tim Bannister <is...@jellybaby.net>.
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 – isoma@jellybaby.net
Re: uds support
Posted by Daniel Lescohier <da...@cbsi.com>.
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 <ji...@jagunet.com> wrote:
>
> On Aug 27, 2013, at 7:09 PM, Daniel Ruggeri <DR...@primary.net> 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 27, 2013, at 7:09 PM, Daniel Ruggeri <DR...@primary.net> 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
Posted by Daniel Ruggeri <DR...@primary.net>.
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
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Aug 23, 2013 at 3:50 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Aug 23, 2013, at 3:37 PM, Tim Bannister <is...@jellybaby.net> 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
Posted by Daniel Ruggeri <DR...@primary.net>.
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 <ji...@jaguNET.com> 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
Re: uds support
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 15, 2013, at 4:57 PM, Blaise Tarr <bl...@gmail.com> wrote:
> On Tue, Oct 15, 2013 at 1:01 PM, Jim Jagielski <ji...@jagunet.com> 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
Posted by Blaise Tarr <bl...@gmail.com>.
On Tue, Oct 15, 2013 at 1:01 PM, Jim Jagielski <ji...@jagunet.com> 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 15, 2013, at 3:33 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 15 Oct 2013, at 7:01 PM, Jim Jagielski <ji...@jaguNET.com> 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
Posted by Graham Leggett <mi...@sharp.fm>.
On 15 Oct 2013, at 7:01 PM, Jim Jagielski <ji...@jaguNET.com> 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Mon, 14 Oct 2013, Jim Jagielski wrote:
> On Oct 14, 2013, at 10:09 AM, Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com> 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 14, 2013, at 10:09 AM, Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com> 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
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <ru...@vodafone.com> 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 <ji...@jaguNET.com> 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.
>>
>> Soooooooo
>>
>> 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
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
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 <ji...@jaguNET.com> 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.
>
> Soooooooo
>
> 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 11, 2013, at 12:24 PM, Jim Jagielski <ji...@jaguNET.com> 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.
Soooooooo
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 23, 2013, at 3:50 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> On Aug 23, 2013, at 3:37 PM, Tim Bannister <is...@jellybaby.net> 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 23, 2013, at 3:37 PM, Tim Bannister <is...@jellybaby.net> 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
Posted by Tim Bannister <is...@jellybaby.net>.
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 – isoma@jellybaby.net