[Paste] Re: X-Sendfile WSGI application

Top Page
Author: Sergey Schetinin
To: Paste Users
Subject: [Paste] Re: X-Sendfile WSGI application
Thanks, Graham. I didn't know about the CGI Location trick.

For anyone else interested in the spec itself, here's the link to the
relevant section: http://tools.ietf.org/html/rfc3875#section-6.2.2

   The script MUST NOT return any other header fields or a message-
   and the server MUST generate the response that it would have
   in response to a request containing the URL

I wonder how other implementations handle the extra headers.

On May 29, 1:44 am, Graham Dumpleton <graham.dumple...@gmail.com>
> On May 27, 6:43 am, Gustavo Narea <m...@gustavonarea.net> wrote:
> > Hello,
> > > This would also be a good place to add a level of indirection and
> > > instead of specifying a fs path for the file to serve, it would be
> > > better to specify an abstract path that the middleware would rewrite
> > > as necessary and possibly use the wrapped app again to get the actual
> > > response body. This would allow better flexibility such as for serving
> > > those files from resources or archives. One thing to note is that one
> > > can go as far as necessary with that path rewriting, for example an
> > > app wants to serve a user avatar and sends "X-Sendfile: /avatar/
> > > username" and given our implementation stores those in in GAE blobs it
> > > might make a lookup to get a blob id for that username and then
> > > rewrite the response headers as necessary so that frontend serves the
> > > actual data.
> > That's interesting, but something like that would need a different
> > name because it's not what X-Sendfile is meant to do.
> The CGI specification defines the ability to return a 'Location' in
> conjunction with a '200' response. The specified path would then be
> interpreted by the web server as a sub request. The target of the sub
> request could be a static file mapped into URL namespace or another
> dynamic resource. The X-Accel-Redirect in nginx is effectively the
> same thing.
> The difference between nginx and Apache is that where you want to send
> a static file which should be private, it is easier in nginx as they
> have a special keyword in the configuration such that you can mark a
> URL mapping as private and so only usable by a sub request. In Apache
> you have to use a mod_rewrite rule to impose the restriction that
> certain URLs should only be accessible as a sub request.
> A long time ago I suggested mirroring this Location/200 behaviour from
> CGI in WSGI in some way. After all we rely on CGI for so much other
> stuff that it seems a logical thing to adopt something it already
> defines. There wasn't any interest back then, but with so many things
> these requirements keep popping later. In this case in this discussion
> but also in an exact same discussion over on Django issue tracker
> where they are trying to come up with extension for Django which does
> same thing.
> For any one interested in playing with the Location/200 mechanism,
> then you can do so by using mod_wsgi and running your WSGI application
> in daemon mode. The feature isn't supported in embedded mode because
> the write() callback from start_response() complicates things,
> although have worked out now how I could do it there now if wanted to.
> Anyway, the purpose of Location/200 seems to match what some here are
> suggesting, which is rather than specify an actual physical file path,
> that you supply an abstract path, with an outer layer deciding what
> that maps to.
> Graham

You received this message because you are subscribed to the Google Groups "Paste Users" group.
To post to this group, send email to paste-users@???.
To unsubscribe from this group, send email to paste-users+unsubscribe@???.
For more options, visit this group at http://groups.google.com/group/paste-users?hl=en.