Fix for no trailing slash

[Mike Auclair]

Switchpipe doesn't seem to know what to do if it receives a request
with no trailing slash, ie http://host/app instead of http://host/app/.
Does a fix like this make sense?

Index: lib/switchpipe.rb
===================================================================
--- lib/switchpipe.rb (revision 44)
+++ lib/switchpipe.rb (working copy)
@@ -571,7 +571,7 @@

# Returns the first directory name in the path requested. This is
the "application name" in SwitchPipe-land.
def app_from_path
- path.include?('/') and path.split('/').first
+ path.include?('/') and path.split('/').first or path
end

# Returns the actual location part of the path, as understood by
SwitchPipe at least.

[Peter Cooper]

On Apr 9, 7:58 pm, Mike Auclair <maucl...@nicusa.com> wrote:
> Switchpipe doesn't seem to know what to do if it receives a request

> with no trailing slash, iehttp://host/appinstead ofhttp://host/app/.

> Does a fix like this make sense?

Thanks!

You're right, although this is something that, typically, a daemon in
front of SwitchPipe would deal with (Apache, for example) or is an
issue that wouldn't occur due to proxying to a version with a slash. I
applied your patch, but it didn't work for me. I rewrote it a little
and still couldn't get it to work. I'm probably missing a simple point
somewhere. Does it work for you?

Cheers,
Peter Cooper

[Mike Auclair]

In my environment, this is pretty much a non-issue because we can,
like you said, handle that in Apache, but I figured I'd post a patch
anyways. Of course, I should have tested it fully first. This should
work better.

Index: lib/switchpipe.rb
===================================================================
--- lib/switchpipe.rb (revision 44)
+++ lib/switchpipe.rb (working copy)

@@ -461,7 +461,7 @@
when :tcp
TCPSocket.new(instance[:host], instance[:port])
end rescue nil
-
+
# If the backend isn't responding, let's just panic and get
outta here..
unless sock
send_data "HTTP/1.1 500 Internal Server Error\r
\nConnection: close\r\nContent-Length: 27\r\nContent-Type: text/plain\r
\n\r\nBackend application failure"
@@ -478,6 +478,7 @@
@request.headers['connection'] = ['Connection', 'close']

# Write out the HTTP request, with some minor changes
(removal of the app identifier path, for one)
+
if found_by == :path
sock.write @request.request_line_without_app + "\r\n" +
@request.header_string + "\r\n\r\n"
else
@@ -571,12 +572,12 @@

# Returns the first directory name in the path requested. This is
the "application name" in SwitchPipe-land.
def app_from_path
- path.include?('/') and path.split('/').first

+ app = path.include?('/') ? path.split('/').first : path

end

# Returns the actual location part of the path, as understood by
SwitchPipe at least.

def path_remainder
- "/#{path.match(/[^\/]+\/(.*)/)[1]}" rescue nil
+ "/#{path.match(/[^\/]+\/(.*)/)[1]}" rescue '/'
end

# Returns the HTTP verb used (GET, POST, PUT, etc)

On Apr 10, 4:17 am, Peter Cooper <pcoo...@gmail.com> wrote:
> On Apr 9, 7:58 pm, Mike Auclair <maucl...@nicusa.com> wrote:
>
> > Switchpipe doesn't seem to know what to do if it receives a request

> > with no trailing slash, iehttp://host/appinsteadofhttp://host/app/.

[Peter Cooper]

Works a treat, Mike. Thanks! Your contribution is already noted in the
README :)

However, after playing with it a bit, I'm thinking we might need to do
this in the same way Apache typically does. That is, if someone goes
to:

http://host/app_name

Then we should redirect (with a 301) to:

http://host/app_name/

The reason for this is that if the app at app_name is using relative
URLs, they won't work on /app_name but will on /app_name/. I guess
this is why Apache takes that route too. This problem can be observed
in the "python_http_server" demo that comes with SwitchPipe.

Whatever eventually happens, thanks for bringing this up!

Pete

[Mike Auclair]

Yeah, I would definitely agree that the 301 approach makes more sense
long term. Also, I'm glad to bring things like this up, since if I
roll SwitchPipe out in my production environment, it will definitely
make life easier for me.

[Peter Cooper]

On Apr 13, 10:44 pm, Mike Auclair <maucl...@nicusa.com> wrote:
> Yeah, I would definitely agree that the 301 approach makes more sense
> long term.  Also, I'm glad to bring things like this up, since if I
> roll SwitchPipe out in my production environment, it will definitely
> make life easier for me.

Definitely keep me / us informed of how this goes :)

Just so you know, another thing I have on the cards is to rewrite all
of SwitchPipe into Python or Perl once the feature set is reasonably
solid. This won't radically improve performance because most of the
latency is in the networking and the process management, but should
make SwitchPipe both easier to deploy and have /some/ performance
benefits.

Pete