Groovy Modules

ParserRegistry: Could not find charset in response

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: HTTPBuilder-0.5.0
  • Fix Version/s: HTTPBuilder-0.5.2
  • Component/s: HttpBuilder
  • Labels:
    None
  • Environment:
    jdk 1.5
    linux
    maven 2.0.10
  • Number of attachments :
    0

Description

I've recently upgrade our project from httpbuilder 0.4.1 to 0.5.0-RC3 and am noticing the following warning everywhere and it's kind of annoying as I don't exactly know the cause and if I should be concerned.

We are using HTTPBuilder.

Here is the warning

Mar 10, 2010 9:21:43 AM groovyx.net.http.ParserRegistry getCharset
WARNING: Could not find charset in response

Is this an issue? Should I be concerned?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Thom Nichols added a comment -

HTTPBuilder will use the platform default charset for parsing the response. I suppose this could be problematic if a Windows platform's default encoding is iso-8859-1 and you happen to be parsing a non-latin response. Same might apply for OSX platforms (I think the default charset there is MacRoman or something?)

I suppose my default response would be "if you don't see any problems, don't worry about it" If everything looks OK then you can just disable warning logging for ParserRegistry.

I know that's not terribly helpful so I'll explain a bit more. Servers should send a charset as part of the Content-Type header in the response. The warning you see indicates that the server didn't provide a charset, so the parser is using the JRE platform default charset. I'm actually not sure if the HTTP spec prescribes how a response should be interpreted if a charset isn't specified.

The safest bet would be to use UTF-8 if a charset isn't given in the response. Maybe I should change ParserRegistry so that you can set a default charset for such cases. Then you can specify the behavior. I'll leave this issue open for such a feature post-0.5.0.

Show
Thom Nichols added a comment - HTTPBuilder will use the platform default charset for parsing the response. I suppose this could be problematic if a Windows platform's default encoding is iso-8859-1 and you happen to be parsing a non-latin response. Same might apply for OSX platforms (I think the default charset there is MacRoman or something?) I suppose my default response would be "if you don't see any problems, don't worry about it" If everything looks OK then you can just disable warning logging for ParserRegistry. I know that's not terribly helpful so I'll explain a bit more. Servers should send a charset as part of the Content-Type header in the response. The warning you see indicates that the server didn't provide a charset, so the parser is using the JRE platform default charset. I'm actually not sure if the HTTP spec prescribes how a response should be interpreted if a charset isn't specified. The safest bet would be to use UTF-8 if a charset isn't given in the response. Maybe I should change ParserRegistry so that you can set a default charset for such cases. Then you can specify the behavior. I'll leave this issue open for such a feature post-0.5.0.
Thom Nichols made changes -
Field Original Value New Value
Assignee Guillaume Laforge [ guillaume ] Thom Nichols [ tomstrummer ]
Issue Type Bug [ 1 ] Improvement [ 4 ]
Fix Version/s HTTPBuilder-0.5.x [ 16230 ]
Priority Major [ 3 ] Minor [ 4 ]
Hide
Permalink
James Lorenzen added a comment -

Thanks. Yeah we are just ignoring it as everything appears to work fine. I just wanted to share my experience to help improve the httpbuilder experience. The warning might also include some text indicating the charset was not included in the response.

Show
James Lorenzen added a comment - Thanks. Yeah we are just ignoring it as everything appears to work fine. I just wanted to share my experience to help improve the httpbuilder experience. The warning might also include some text indicating the charset was not included in the response.
Hide
Permalink
Wenca added a comment -

I have the same problem. The response is in utf-8 but the header is not provided by the server. But the default encoding on platform is different and the data stored are corrupted. The suggested sollution would be perfect. Thanks.

Maybe I should change ParserRegistry so that you can set a default charset for such cases. Then you can specify the behavior.

Show
Wenca added a comment - I have the same problem. The response is in utf-8 but the header is not provided by the server. But the default encoding on platform is different and the data stored are corrupted. The suggested sollution would be perfect. Thanks. Maybe I should change ParserRegistry so that you can set a default charset for such cases. Then you can specify the behavior.
Hide
Permalink
Thom Nichols added a comment -

I'll fix this for the next release. Stay tuned.

Show
Thom Nichols added a comment - I'll fix this for the next release. Stay tuned.
Hide
Permalink
Thom Nichols added a comment -

Sorry I took so long to fix this; you will now have a static property on `ParserRegistry` to set the default charset used for parsing if one is not given. Hoping to release 0.5.2 soon.

Committed in r917

Show
Thom Nichols added a comment - Sorry I took so long to fix this; you will now have a static property on `ParserRegistry` to set the default charset used for parsing if one is not given. Hoping to release 0.5.2 soon. Committed in r917
Thom Nichols made changes -
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s HTTPBuilder-0.5.2 [ 16983 ]
Fix Version/s HTTPBuilder-0.5.x [ 16230 ]
Resolution Fixed [ 1 ]

People

  • Assignee:
    Thom Nichols
    Reporter:
    James Lorenzen
Vote (2)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: