I just noticed something interesting (or not) about getting to my RoR
app on the 2 browsers. I’ve tested it running Webrick or Mongrel_rails
and get the same behavior.
Specifying that complete URL works fine in both browsers. However in IE
if you just specify www.mydomain.com:myport#/app/list I get page not
found. In FF the URL without the http:// works fine.
I know down the road we need to update our server to use Apache with
fastcgi or lighttpd rather than using webrick or mongrel, but I am
curious as to why this is happening and how to “fix” it if possible.
Our server is a standard Centos server with numerous virtual servers
running on it. mydomain.com is just one account of many that happens to
be where I am developing a ruby app. To start my server I merely cd app
then start webrick or mongrel_rails. I have done nothing further for
routing etc.
Specifying that complete URL works fine in both browsers. However in IE
if you just specify www.mydomain.com:myport#/app/list I get page not
found. In FF the URL without the http:// works fine.
I know down the road we need to update our server to use Apache with
fastcgi or lighttpd rather than using webrick or mongrel, but I am
curious as to why this is happening and how to “fix” it if possible.
IE cannot access urls on non-standard ports without a full url
(including the protocol). Without changing the port to 80, there’s no
way to get around this (as Apache, webrick, mongrel, etc. never get
sent the request).
I know down the road we need to update our server to use Apache with
fastcgi or lighttpd rather than using webrick or mongrel, but I am
curious as to why this is happening and how to “fix” it if possible.
I ran into a related issue a few days ago. If you look into the
RFC2396 for the “Uniform Resource Identifiers (URI): Generic Syntax” http://www.ietf.org/rfc/rfc2396.txt, you’ll discover that without the
http: this is indistinguishable from an opaque URI for the scheme
“www.mydomain.com:”. (Read Section 3 or take my word for it
FF decides to “guess” that you might mean http:// probably after
failing to recognize the URI as entered. I hate to say that IE might
actually be doing it right (that almost hurts to say).
I discovered the problem only because I always type the scheme, but
someone else didn’t and the way that the code attempted to resolve
the problem had a bug (naturally) when just a hostname was given.
Specifying that complete URL works fine in both browsers. However in IE
if you just specify www.mydomain.com:myport#/app/list I get page not
found. In FF the URL without the http:// works fine.
I know down the road we need to update our server to use Apache with
fastcgi or lighttpd rather than using webrick or mongrel, but I am
curious as to why this is happening and how to “fix” it if possible.
IE cannot access urls on non-standard ports without a full url
(including the protocol). Without changing the port to 80, there’s no
way to get around this (as Apache, webrick, mongrel, etc. never get
sent the request).
Tom
This is what I was thinking as well, I don’t know of anything else that
would cause it.
with IE “host.domain:port/page” will not work but
“http://host.domain:port/page” will.
As was mentioned this only has to do with the browser not sending the
request, there’s you can do to change the behavior.
I just noticed something interesting (or not) about getting to my RoR
app on the 2 browsers. I’ve tested it running Webrick or Mongrel_rails
and get the same behavior.
Without the leading slash the request is basically junk. I’m guessing
firefox is throwing in some extra slashes to keep the server happy, but
if you just drop the # then you’re good. Or, use the full URI path
(like everyone else on the internet).
Is there a compelling reason that you’re using this type of URI?
Specifying that complete URL works fine in both browsers. However in IE
if you just specify www.mydomain.com:myport#/app/list I get page not
found. In FF the URL without the http:// works fine.
I know down the road we need to update our server to use Apache with
fastcgi or lighttpd rather than using webrick or mongrel, but I am
curious as to why this is happening and how to “fix” it if possible.
Another question: why do you have to move to fastcgi? Because the
above URI won’t work?
You should also turn on debugging and see what the logs in
log/mongrel_debug/ tell you:
mongrel_rails start -B
Then look at log/mongrel_debug/rails.log for information on what rails
is receiving from Mongrel, and log/mongrel_debug/files.log for what
Mongrel thinks the URI is.
Just to clarify, while that’s probably not something you want to be
confusing webservers with, it -is- a valid URI according to RFC 3986.
(FYI, Rob, http://www.ietf.org/rfc/rfc3986.txt obsoletes RFC 2396.)
If you apply the simple scheme-based normalization algorithm (in this
case, http-based) described in RFC 3986, you end up with the following
URI, and I believe that’s what Firefox does:
Well I enabled the mongrel debugging and as Tom above pointed (I
believe) the request never gets that far. Someone mentioned configuring
Apach as a transparent proxy. I haven’t really done much Apache
diddling, could someone elaborate on how to do this for a specific
domain and port to map my application?
Also thanks for all the great responses. The Rails community is quite
extensive and very supportive to those of us coming up to speed.
Just to clarify, while that’s probably not something you want to be
confusing webservers with, it -is- a valid URI according to RFC 3986.
(FYI, Rob, http://www.ietf.org/rfc/rfc3986.txt obsoletes RFC 2396.)
Hadn’t seen that one. The uri code in 1.8.4 still refers to 2396.
