You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2017/03/06 17:22:09 UTC

Re: "mime-mapping" and Content-Type

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ryan,

On 2/27/17 9:50 AM, Ryan Yohnk wrote:
> I wasn\u2019t aware there was a servlet in-between simple requests like 
> you stated. But that makes perfect sense.

Something has to serve the bytes. In a Java web application server,
that's called the DefaultServlet.

> As noted in the SO post, I can see that 
> StandardContext:addMimeMapping() is being called with my specific 
> mapping during initialization. But I\u2019m never seeing the backing 
> mimeMappings called from there.

Right: because you are never consulting that mapping.

> I\u2019ve seen quite a few online posts on this topic but can\u2019t seem 
> find any official documentation for 8+. Is this feature something 
> that\u2019s still supported? If so, is there something I\u2019m overlooking 
> in my test or configuration?

I think you are misunderstanding what's going on entirely.

> Any light you guys can shine on the subject would be greatly 
> appreciated.

If you have a file on the disk called foo.swa, and you request it
using http://example.com/myapp/foo.swa and the DefaultServlet serves
the bytes off the disk, then the DefaultServlet will use the .swa
extension plus your mime-mapping to produce the "Content-Type:
text/rtf;charset=UTF-8" response header.

In your situation, your servlet is handling the request, and the
DefaultServlet isn't involved. Tomcat doesn't magically add response
headers based upon the URLs used to choose the servlet to serve the
bytes. Your own servlet is responsible for setting whatever response
headers it wants to use.

Tomcat will automatically add the following headers:

- - Date
- - Content-Encoding: chunked (if the response is committed and not yet
complete)
- - Content-Length (if not chunked)


... but nothing else. If you want a Content-Type header, you'll have
to add it yourself.

Here's your code:

> Servlet:
> 
> public class SimpleServlet extends HttpServlet { protected void
> doGet(HttpServletRequest req, HttpServletResponse resp) throws
> ServletException, IOException { IOUtils.write("Hello There!",
> resp.getOutputStream()); resp.setStatus(202); } }

You aren't writing any Content-Type header, so you aren't getting one.
If you want to add a Content-Type header, just do it:

public class SimpleServlet extends HttpServlet {
  protected void doGet(HttpServletRequest req,
                       HttpServletResponse resp)
    throws ServletException, IOException {
    IOUtils.write("Hello There!", resp.getOutputStream());
    resp.setContentType("text/plain");
    resp.setStatus(202);
  }
}

Or, if you want to detect the correct MIME type from the URL, you
could do this:

  ServletContext app = req.getServletContext();
  String mimeType = app.getMimeType(req.getRequestURI());
  resp.setContentType(mimeType);

>> You said you don't want to modify the source... what about
>> *adding* to it? Would it be okay to write a Filter and add it to
>> the configuration of the application? That is a very easy thing
>> to do, and you can add whatever headers you want for whatever
>> reason.
> 
> Yep, a filter will be the next step. Honestly that\u2019s the behavior 
> I\u2019m describing anyway. My initial hope was to keep the changes 
> limited to Tomcat configuration but if that\u2019s not possible that\u2019s 
> cool.
> 
> Since it seems like a pretty common filter, is anyone aware of an 
> existing implementation? I know it\u2019s pretty trivial but no sense
> in rewriting the wheel if it\u2019s already out there.

I'm not sure it's that common of a request. Usually the servlet knows
the type of data it returns, and sets the content-type accordingly. I
haven't seen many servlets that sometimes serve PDFs and sometimes
server plain-text responses, and can only tell the difference when the
request URL has a particular filename-looking-thing in it that has a
recognizable "file extension" (which is just a convention, of course).

If you wanted to write a filter that could do this kind of thing, it
would be only a few lines long:

public class MimeTypeFromURIFilter
    implements Filter {
  // ignoring init() and destroy() methods

  public void invoke(ServletRequest request,
                     ServletResponse response,
                     FilterChain chain)
    throws ServletException {

    // Don't clobber any existing content-type
    if(null == response.getContentType()) {
      ServletContext app = req.getServletContext();
      String mimeType = app.getMimeType(req.getRequestURI());
      response.setContentType(mimeType);
    }

    // You could also put this before the Content-Type check,
    // but it's possible that the response could be committed
    // by the filter chain (or servlet) and then the Content-Type
    // header wouldn't be included in the response.
    chain.doFilter(request, response);
  }
}

Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYvZrBAAoJEBzwKT+lPKRYvroP/2kAnMDVRzWKKq94ovIYz5Nc
U5mnHQ2p4D3a2x4hxlfCiYDhOiwbSGK6GRLoD8fDVUnEJdux+XRvA8laAdMAcPV8
6BbvpqdqYSDzTkgzBM99LJDiaoGTef5nHUvz7XyS8Wvp0JVDz22fcDGqEdjvL/yd
/doLczuUGcqOkjrxqTpTVm5OYKF+wvrMJbPKt9zgtdDhEbIGe0rWY8Dl7ku+PHJq
SGTopaxwFE7JUGqVUcFNDtxf2ouF7R7T3FJ+dGJb93CzAcdL18o5z6qoLzxg3Ph6
EsL6mGnRIpJOBI0ZOuHFpGg4euXR8paXjinUktOaIWmv75vBCebyrAkN50CyVLmn
fN8zz64VT+zdK6UXN1k7h8/ZZopubZAcW/Gx9qDVbqqX4b6kaY1X1+zsJKOC4/db
IvXCNIB1UkPcx2warhkmpG+aaH95I7hv2JQJejqUqMjyWfBSnk6hwLyhJMqqtxUw
1FXQL+J90hzvbmIbt3OUAsrccgaXgNs9NEHLWII2y4Igjtd+ERjCN3IIDFQyMl/P
tNQaVc655dMu3B7b/8GaE8MnNBBjOau6bYDh4F7YC2BqBwTEl/RXpoluTOrMOEmA
9N/JF1a35aXSo+3YDQB09qeZbL6ptNNBH2KyiPy0Q4JJ4bo92NI1WXcez0FcJLN2
Y/KdjbOfiOOHv7fOGXAd
=k9bv
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org