Groovy Modules
  1. Groovy Modules
  2. GMOD-131

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

        Hide
        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
        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
        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
        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
        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
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: