CODEWITHSUNDEEP
servletsjakarta-eewildflyservlet-3.0
hrs
hrs

Reputation: 417

Serving static content programmatically from Servlet - does the spec have anything available or i should roll a custom one?

I have a db with original file names, location to files on disk, meta data like user that owns file... Those files on disk are with scrambled names. When user requests a file, the servlet will check whether he's authorized, then send the file in it's original name.

While researching on the subject i've found several cases that cover that issue, but nothing specific to mine.

Essentially there are 2 solutions:

  1. A custom servlet that handles headers and other stuff the Default Servlet containers don't: http://balusc.omnifaces.org/2009/02/fileservlet-supporting-resume-and.html
  2. Then there is the quick and easy one of just using the Default Servlet and do some path remapping. For ex., in Undertow you configure the Undertow subsystem and add file handlers in the standalone.xml that map http://example.com/content/ to /some/path/on/disk/with/files .

So i am leaning towards solution 1, since solution 2 is a straight path remap and i need to change file names on the fly.

I don't want to reinvent the hot water. And both solutions are non standard. So if i decide to migrate app server to other than Wildfly, it will be problematic. Is there a better way? How would you approach this problem?

Upvotes: 0

Views: 207

Answers (1)

stdunbar
stdunbar

Reputation: 17555

While your problem is a fairly common one there isn't necessarily a standards based solution for every possible design challenge.

I don't think the #2 solution will be sufficient - what if two threads try to manipulate the file at the same time? If someone got the link to the file could they share it?

I've implemented something very similar to your #1 solution - the key there is that even if the link to the file got out no one could reuse the link as it requires security. You would just "return" a 401 or 403 for the resource.

Another possibility depends on how you're hosted. Amazon S3 allows you to generate a signed URL that has a limited time to live. In this way your server isn't sending the file directly. It is either sending a redirect or a URL to the front end to use. Keep the lifetime at like 15 seconds (depending on your needs) and then the URL is no longer valid.

I believe that the other cloud providers have a similar capability too.

Upvotes: 1

Related Questions