Shane, This is certainly possible and there are lots of different ways to skin this particular cat.
One would be to have a filter that intercepts the request to the base64 encoded identifier and it works out the real resource. It then does an RequestDispatcher.forward to a named dispatcher obtained for "default", which is the jetty default servlet. This way the real path is hidden from the client. Another way to proceed is to write a servlet that uses the Jetty APIs directly for sending the file efficiently and asynchronously. This may be able to offer you more flexibility. The decision to use fast memory mapped buffers could depend somewhat if the file is to be served only once or many many times. If it is to be served only once, it may be better to have a large direct buffer that reads/writes the content. Jetty-9 has some APIs to do that with file channels. However, I still am a bit vague about some of the details of you scheme. What dose the X-Accel-Redirect header do? Is it the client that handles that header? or is it just doing some signalling between the CFML and nginx? cheers On 11 June 2013 04:13, Shane Curless <[email protected]> wrote: > Let me see if I can explain it a bit better... > > - User logs into our Information Management System. > - User wants to download a file. The meta-information is store in a > database, and the physical file is stored in a private directory on the > server, the name of which is generated from the File ID and Revision ID. > This physical, on-disk file name and path should never be seen by the > client. > - The users is directed to a URL, /files/(base64-encoded identifier), which > via URL rewriting is handled by a CFML page. > - The CFML page decodes the identifier, authenticates the session, and if > all is well, builds a path to the physical file. > - The CFML page sets the response header "X-Accel-Redirect" to this path. > > At this point, Railo is done processing and control is returned to the > servlet container. > > - Nginx intercepts this response header, and responds to the browser with > the content of the file. > This is the part that I want Jetty to do, without having to make the path > publically available. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Simone Bordet > Sent: June-10-13 2:05 PM > To: JETTY user mailing list > Subject: Re: [jetty-users] Jetty 9 as a Front-end Server > > Hi, > > On Mon, Jun 10, 2013 at 7:49 PM, Shane Curless <[email protected]> > wrote: > > I'm not sure what you mean by mapping to DefaultServlet.. I don't want > > these files to be directly available to the public. And I need to use > > Content-Disposition to output the real filename stored in a database. > > Well then you have to be more precise in your use case. > I am not familiar with Railo, nginx, <cfheader> or whatever you're doing. > I know Jetty can serve content asynchronously via direct buffers, and I > believe what you have tersely described in your emails, if I understood it > correctly, is doable in Jetty. > > -- > Simone Bordet > ---- > http://cometd.org > http://webtide.com > http://intalio.com > Developer advice, training, services and support from the Jetty & CometD > experts. > Intalio, the modern way to build business applications. > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins <[email protected]> http://www.webtide.com Developer advice and support from the Jetty & CometD experts. Intalio, the modern way to build business applications.
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
