dev@grizzly.java.net

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

From: Bongjae Chang <bongjae.chang_at_gmail.com>
Date: Sun, 12 Jan 2014 14:41:39 +0900

Hi Alexey,
You are right. When I tested it with 2.3.x trunk(rev. fd67e84), it worked
well!
Thanks!

Regards,
Bongjae Chang


From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Reply-To: <dev_at_grizzly.java.net>
Date: Sunday, January 12, 2014 2:45 AM
To: <dev_at_grizzly.java.net>
Subject: Re: Request's content-type value was null when I used
MultipartScanner.

    
 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
>
>