From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.229.225.21 with SMTP id iq21cs91311qcb; Sun, 28 Nov 2010 06:52:38 -0800 (PST) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCMbRn8eQDxC02cnnBBoEo9GZBg@googlegroups.com designates 10.229.43.139 as permitted sender) client-ip=10.229.43.139; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCMbRn8eQDxC02cnnBBoEo9GZBg@googlegroups.com designates 10.229.43.139 as permitted sender) smtp.mail=rack-devel+bncCMbRn8eQDxC02cnnBBoEo9GZBg@googlegroups.com; dkim=pass header.i=rack-devel+bncCMbRn8eQDxC02cnnBBoEo9GZBg@googlegroups.com Received: from mr.google.com ([10.229.43.139]) by 10.229.43.139 with SMTP id w11mr2038796qce.22.1290955958490 (num_hops = 1); Sun, 28 Nov 2010 06:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received:received-spf:received:mime-version:received :received:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type; bh=Z/+OT1N/FrQJZuY5UBh3pMMNKgFltItPELJpzVfQsfQ=; b=Ow1gRDSD90z6kOE6WpvLG4Xbv8ykQ/8J4ay5jIYLDVbLncgF5fjSyY1Cd+08iW3kVv XBFUkRc1vWy4Jz4WXyOiCijpuTOY7snGRW1Eeem70LMQ66fTji8Um9HrnhKY/7mfc3IM p76Xq2F/9xsa4VvbBONaGuAmMg9GQQ12CXjTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type; b=vTDqhri2w8skWSQhzCNMVC3qTBaqTR06dvMMKWa4I9tVWVW3OmllNOG+6jVgFvVOOj i0F6DM7eZPym61j/neeg/xqmFqEa586GjPQfH1YHcqZg1jr0evSgVDoApdNjj6sOZkhx PD/ENc6gXXfU4QtcXPvI2WfgcsNLl6p5Su4t0= Received: by 10.229.43.139 with SMTP id w11mr372974qce.22.1290955956424; Sun, 28 Nov 2010 06:52:36 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.224.166.70 with SMTP id l6ls822316qay.2.p; Sun, 28 Nov 2010 06:52:36 -0800 (PST) Received: by 10.224.37.9 with SMTP id v9mr312102qad.8.1290955956030; Sun, 28 Nov 2010 06:52:36 -0800 (PST) Received: by 10.229.236.199 with SMTP id kl7mr445190qcb.18.1290955621018; Sun, 28 Nov 2010 06:47:01 -0800 (PST) Received: by 10.229.236.199 with SMTP id kl7mr445189qcb.18.1290955620957; Sun, 28 Nov 2010 06:47:00 -0800 (PST) Received: from mail-qw0-f46.google.com (mail-qw0-f46.google.com [209.85.216.46]) by gmr-mx.google.com with ESMTP id ey28si858037qcb.15.2010.11.28.06.46.59; Sun, 28 Nov 2010 06:46:59 -0800 (PST) Received-SPF: pass (google.com: domain of lee.hambley@gmail.com designates 209.85.216.46 as permitted sender) client-ip=209.85.216.46; Received: by mail-qw0-f46.google.com with SMTP id 7so3556747qwb.19 for ; Sun, 28 Nov 2010 06:46:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.19.138 with SMTP id a10mr4153598qab.30.1290955619779; Sun, 28 Nov 2010 06:46:59 -0800 (PST) Received: by 10.220.192.199 with HTTP; Sun, 28 Nov 2010 06:46:59 -0800 (PST) In-Reply-To: References: Date: Sun, 28 Nov 2010 15:46:59 +0100 Message-ID: Subject: Re: Problem with redirects where a Rack app sits behind a proxy From: Lee Hambley To: rack-devel@googlegroups.com X-Original-Sender: lee.hambley@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of lee.hambley@gmail.com designates 209.85.216.46 as permitted sender) smtp.mail=lee.hambley@gmail.com; dkim=pass (test mode) header.i=@gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary=0015175cb2802346f104961e07e1 --0015175cb2802346f104961e07e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jon, it's the responsibility of your proxy to set X-Forwarded-For, and of the Application to check :port if it cares about the real port, or the X-Forwarded-For list in the case that you acknowledge the request might be proxied. Often XFF can be used to trick sites that use it for some `security` (not your case) as the client can spoof it. In case you use NGinx, at least you can specify to proxy transparently (completely) - so your app wouldn't be any wiser. Some proxies (Akamai) will also set a True-Client-IP header to the value se= t last in XFF. =E2=80=A2 http://en.wikipedia.org/wiki/X-Forwarded-For Hope that makes sense Jon (would be nice to have a standard Ruby way to loo= k at the proxies & original client info from the `smart` places, as it comes up for a lot of people. Here's a snippet of a nginx backend configuration that solved this in the easiest way for me. https://gist.github.com/46cc2ba95794f5c92693 - Lee On 28 November 2010 15:21, Jon Leighton wrote: > Hi there, > > I have encountered a problem with redirects with Sinatra proxied by > Apache. Basically, the port number of the backend application server > (Mongrel or whatever) will appear in the Location header. > > I've done a fairly extensive investigation here: > https://github.com/jonleighton/redirect_test > > If you read README.md it basically explains everything in detail, but > what it boils down to is this: Rack::Request#port is incorrect, in > that it uses SERVER_PORT when no explicit port is given by > host_with_port. > > Rails is not affected, since it implements its own > ActionDispatch::Request#port method. I believe the Rails > implementation is correct and should be implemented in Rack. > > If people agree with this analysis then I'm happy to produce a patch > against Rack. > > Cheers, > Jon > > -- > http://jonathanleighton.com/ --0015175cb2802346f104961e07e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jon, it's the responsibility of your proxy to set X-Forwarded-For, and = of the Application to check :port if it cares about the real port, or the X= -Forwarded-For list in the case that you acknowledge the request might be p= roxied.

Often XFF can be used to trick sites that use it for some `s= ecurity` (not your case) as the client can spoof it.

In case you use NGinx, at least you can specify to proxy transparently (= completely) - so your app wouldn't be any wiser.

Some proxies (Akamai) will also set a True-Client-IP he= ader to the value set last in XFF.


Hope that makes sense Jon (would be nice to have a standard Ruby w= ay to look at the proxies & original client info from the `smart` place= s, as it comes up for a lot of people. Here's a snippet of a nginx back= end configuration that solved this in the easiest way for me. https://gist.github.com/46cc2ba= 95794f5c92693

- Lee =C2=A0

O= n 28 November 2010 15:21, Jon Leighton <j@jonathanleighton.com> wrote:
Hi there,

I have encountered a problem with redirects with Sinatra proxied by
Apache. Basically, the port number of the backend application server
(Mongrel or whatever) will appear in the Location header.

I've done a fairly extensive investigation here: https://github.com/jon= leighton/redirect_test

If you read README.md it basically explains everything in detail, but
what it boils down to is this: Rack::Request#port is incorrect, in
that it uses SERVER_PORT when no explicit port is given by
host_with_port.

Rails is not affected, since it implements its own
ActionDispatch::Request#port method. I believe the Rails
implementation is correct and should be implemented in Rack.

If people agree with this analysis then I'm happy to produce a patch against Rack.

Cheers,
Jon

--
http://jonathanl= eighton.com/

--0015175cb2802346f104961e07e1--