Re: Invalid HTTP format, parsing fails.

2,709 views
Skip to first unread message

Jonne Haß

unread,
Sep 26, 2012, 10:00:56 AM9/26/12
to diaspora...@googlegroups.com
Hey,

please do not crosspost, diaspora-discuss is the only right place for
troubleshooting help ;).

In basically all cases I've seen a "!! Invalid request" that was
because the appserver was accessed via HTTPS. So here comes the
checklist:

1. If you cannot reverse proxy ensure that the SSL requirement is
turned off in your configuration. (circumvent_ssl_requirement: true
currently, require_ssl: false in the future).
2. If you do reverse proxy:
2a. Ensure the upstream resource is accessed via http not https
2b. Ensure the proxy sets the X-Forwarded-Proto header to "https"
3. After you fixed the unwanted redirect with one of the two methods
above: clear your browser cache, browsers do cache redirects!


On Wed 26 Sep 2012 02:13:14 PM CEST, rune wrote:
> Hi,
>
> I'm new to diaspora and am installing a POD for the first time.
>
> All has gone fine and I can run an instance using "./scripts/server"
>
> However, when I try to access http://myhost:3000 i get the following
> error from Thin:
> mina diaspora # ./script/server
> >> Using rack adapter
> Rack::SSL is enabled
> Rack::SSL is enabled
> >> Thin web server (v1.4.1 codename Chromeo)
> >> Debugging ON
> >> Maximum connections set to 1024
> >> Listening on 0.0.0.0:3000, CTRL+C to stop
> !! Invalid request
> Invalid HTTP format, parsing fails.
>
> /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.4.1/lib/thin/request.rb:82:in
> `execute'
>
> /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.4.1/lib/thin/request.rb:82:in
> `parse'
>
> /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.4.1/lib/thin/connection.rb:38:in
> `receive_data'
>
> /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in
> `run_machine'
>
> /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in
> `run'
>
> /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.4.1/lib/thin/backends/base.rb:63:in
> `start'
>
> /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.4.1/lib/thin/server.rb:159:in
> `start'
>
> /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.4.1/lib/thin/controllers/controller.rb:86:in
> `start'
>
> /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.4.1/lib/thin/runner.rb:185:in
> `run_command'
>
> /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.4.1/lib/thin/runner.rb:151:in
> `run!'
> /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.4.1/bin/thin:6:in
> `<top (required)>'
> /usr/local/bin/thin:23:in `load'
> /usr/local/bin/thin:23:in `<main>'
>
>
> Any assistance would be greatly appreciated!
>
> Kind regards
>
>
> Simon

rune

unread,
Sep 26, 2012, 4:56:49 PM9/26/12
to diaspora...@googlegroups.com
On Wednesday, 26 September 2012 15:01:01 UTC+1, Jonne Haß wrote:
Hey,

please do not crosspost, diaspora-discuss is the only right place for
troubleshooting help ;).
Hey Jonne,

Thanks for your reply.

My apologies for crossposting, I posted  on the dev list by mistake. When I realised I had not posted to the correct list, I posted to this list instead. :-)
 
In basically all cases I've seen a "!! Invalid request" that was
because the appserver was accessed via HTTPS. So here comes the
checklist:

1. If you cannot reverse proxy ensure that the SSL requirement is
turned off in your configuration. (circumvent_ssl_requirement: true
currently, require_ssl: false in the future).

I have tried this. It seems if I turn SSL off I can access D* on pork 3000
2. If you do reverse proxy:

I am trying to, yes
 
2a. Ensure the upstream resource is accessed via http not https
 
2b. Ensure the proxy sets the X-Forwarded-Proto header to "https"

Ok, this is what I have:
<VirtualHost <ip>:80>
  ServerName diaspora.mydomain
  RedirectPermanent / https://diaspora.mydomain/
</VirtualHost>
<VirtualHost 208.111.39.76:443>
 ServerName diaspora.mydomain

 DocumentRoot /opt/diaspora/public

 RewriteEngine On

 RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
 RewriteRule ^/(.*)$ balancer://thinservers%{REQUEST_URI} [P,QSA,L]

 <Proxy balancer://thinservers>
  BalancerMember http://127.0.0.1:3000
 </Proxy>
 
3. After you fixed the unwanted redirect with one of the two methods
above: clear your browser cache, browsers do cache redirects!

At present, this is still not working for me. I'm a little unclear. Are you saying that I run without SSL enabled in D* and Apache will take care of the SSL for me? Does this mean I can ignore the warning in application.yml that things will not work if I don't use SSL?

Thanks again for your help.

Kind regards

Simon

Jonne Haß

unread,
Sep 26, 2012, 5:00:44 PM9/26/12
to diaspora...@googlegroups.com
D* does not handle SSL but just does redirect from HTTP to HTTPS. The
setting disables that redirect, so you always need a reverse proxy to
handle the SSL decoding. If you add " RequestHeader set
X_FORWARDED_PROTO https" to your virtual host you should be fine
regardless on what value that setting is.

rune

unread,
Sep 26, 2012, 5:08:46 PM9/26/12
to diaspora...@googlegroups.com


On Wednesday, 26 September 2012 22:00:59 UTC+1, Jonne Haß wrote:
D* does not handle SSL but just does redirect from HTTP to HTTPS. The
setting disables that redirect, so you always need a reverse proxy to
handle the SSL decoding. If you add " RequestHeader set
X_FORWARDED_PROTO https" to your virtual host you should be fine
regardless on what value that setting is.

That's interesting. Although I neglected to paste it in my last post, I do actually have that already but I get the Invalid Format error still.

Other  lines from my config:

 ProxyRequests Off
 ProxyVia On
 ProxyPreserveHost On
 RequestHeader set X_FORWARDED_PROTO https

 <Proxy *>
  Order allow,deny
  Allow from all
 </Proxy>

 <Directory /opt/diaspora/public>
  Allow from all
  AllowOverride all
  Options -MultiViews
 </Directory>


rune

unread,
Oct 2, 2012, 5:30:33 AM10/2/12
to diaspora...@googlegroups.com, si...@hacknix.net

Hi,

I just wanted to say thanks for the help. My pod is now mostly working, but I have a problem with federation which I will post in a new thread. Thanks again!

Simon

Reply all
Reply to author
Forward
0 new messages