dev@grizzly.java.net

Re: Request's content-type value was null when I used MultipartScanner.

From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Date: Sat, 11 Jan 2014 09:45:37 -0800

Hi Bongjae,

I found similar issue, when trying to integrate the latest Grizzly into
Glassfish.
https://java.net/jira/browse/GRIZZLY-1637

The fix is commited, can you pls. double check if your code works with
2.3.x trunk.

Thank you.

WBR,
Alexey.

On 11.01.14 09:17, Bongjae Chang wrote:
> Hi,
> I met a problem when I used MultipartScanner#scan() at Grizzly 2.3.8
> or 2.3.9.
> --
> MultipartScanner.java:85
> 84: final String contentType = request.getContentType(); //
> HttpHeader#getContentType()
> 85: String[] contentTypeParams = contentType.split(";"); // NPE
> because of contentType was null.
> --
> When I debugged the
> Requests(org.glassfish.grizzly.http.server.Request.java), the object
> already contained the content-type header(both key and value) in
> parameters field and raw HttpRequestPacket object, but maybe
> HttpHeader#getContentType() returned a wrong value(null).
>
> I think that the content-type had the chance which could be set at
> ServerHttpRequestImp#parseContentTypeHeader() but contentType.isSet()
> was true because contentType.isMimeTypeSet() was true.
>
> --
> In HttpServerFilter.java
> ..
> private void parseContentTypeHeader() {
> contentTypeParsed = true;
> if (!contentType.isSet()) {
> ..
> // the logic of setting content type
> }
> }
> --
> In ContentType.java
> ..
> public boolean isMimeTypeSet() {
> return !isParsed || mimeType != null; // isParsed is default true.
> }
> --
>
> When I tested the same logic at Grizzly 2.3.7, I didn't meet this issue.
>
> Perhaps, could this be the side-effect of Issue
> #1032(https://java.net/jira/browse/GRIZZLY-1032)? :-)
>
> Regards,
> Bongjae Chang