From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.229.235.202 with SMTP id kh10csp154847qcb; Wed, 18 Jul 2012 09:39:43 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCOWCoOrMChDOzZuABRoEWIyW5A@googlegroups.com designates 10.50.6.130 as permitted sender) client-ip=10.50.6.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCOWCoOrMChDOzZuABRoEWIyW5A@googlegroups.com designates 10.50.6.130 as permitted sender) smtp.mail=rack-devel+bncCOWCoOrMChDOzZuABRoEWIyW5A@googlegroups.com; dkim=pass header.i=rack-devel+bncCOWCoOrMChDOzZuABRoEWIyW5A@googlegroups.com Received: from mr.google.com ([10.50.6.130]) by 10.50.6.130 with SMTP id b2mr3256688iga.5.1342629582727 (num_hops = 1); Wed, 18 Jul 2012 09:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=x-beenthere:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-google-group-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe:content-type; bh=NIVCRgnymk+kcW4gFU+bIE9lfu6M6D7kGdFuhrgaM/Y=; b=EX03nBpCsEnwNbCJw2x+uW5fXKO7ozd9hTirMsO0UNrNsbqDcpvDVONz+CkxM5HlFv Y0vZr/CaHR5FiWS9fKXFjGO6OYgr6h/WL8VnFE9L62cYsnT8hXirSULctAncBzRFIUUR CmoniUr/wswzSRH5G33lGrfCUXfErp4xFNV4M= Received: by 10.50.6.130 with SMTP id b2mr574421iga.5.1342629582653; Wed, 18 Jul 2012 09:39:42 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.50.160.202 with SMTP id xm10ls2172067igb.3.gmail; Wed, 18 Jul 2012 09:39:41 -0700 (PDT) Received: by 10.42.161.193 with SMTP id u1mr325528icx.20.1342629581188; Wed, 18 Jul 2012 09:39:41 -0700 (PDT) Received: by 10.50.100.229 with SMTP id fb5msigb; Wed, 18 Jul 2012 09:20:52 -0700 (PDT) Received: by 10.68.129.194 with SMTP id ny2mr537285pbb.17.1342628451420; Wed, 18 Jul 2012 09:20:51 -0700 (PDT) Date: Wed, 18 Jul 2012 09:20:49 -0700 (PDT) From: Theo Cushion To: rack-devel@googlegroups.com Message-Id: <0840a6b3-1fbf-499e-b5f2-0fd63fbf1abf@googlegroups.com> Subject: Rack::Sendfile and X-Accel-Mapping MIME-Version: 1.0 X-Original-Sender: mrtheo@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: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary="----=_Part_7_33443881.1342628449467" ------=_Part_7_33443881.1342628449467 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, I'm using Rack::Sendfile (via Rails) and was wondering if someone could explain if what I'm experiencing is deliberate, or could be changed. I've noticed when nginx adds the header "X-Sendfile-Type: X-Accel-Redirect", then Rack::Sendfile will jump into action. If the header "X-Accel-Mapping" is missing then it will not interfere. However, if both of the headers are present it will take over - even if the mapping cannot be resolved. This doesn't make sense to me, as if the X-Accel-Mapping does not match the path of the file that is being attempted to send, then surely Rack:Sendfile should not interfere so that the file can be sent successfully albeit less efficiently? Cheers Theo ------=_Part_7_33443881.1342628449467 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi,

I'm using Rack::Sendfile (via Rails) and was wondering if someone could explain if what I'm experiencing is deliberate, or could be changed.

I've noticed when nginx adds the header "X-Sendfile-Type: X-Accel-Redirect", then Rack::Sendfile will jump into action. If the header "X-Accel-Mapping" is missing then it will not interfere. However, if both of the headers are present it will take over - even if the mapping cannot be resolved.

This doesn't make sense to me, as if the X-Accel-Mapping does not match the path of the file that is being attempted to send, then surely Rack:Sendfile should not interfere so that the file can be sent successfully albeit less efficiently?

Cheers

Theo

------=_Part_7_33443881.1342628449467--