Null charset issue on a 401 Unauthorized response

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a MS .NET HttpListener service with authentication 
   (i.e. AuthenticationSchemes.Basic) 
2. Connect RESTClient to the service without selecting an "Auth Type".

What is the expected output? What do you see instead?

In version 2.3.0 the client would display status: "HTTP/1.1 401
Unauthorized" and one of the response headers would be
"WWW-Authenticate" with a value of "Basic realm="<whatever>".

It was fairly easy to determine what action needed to be taken to
further interact with the service.

In version 2.3.2, you simply receive and error dialog with the
following:

Null charset name
java.lang.IllegalArgumentException: Null charset name
    at java.nio.charset.Charset.lookup(Unknown Source)
    at java.nio.charset.Charset.forName(Unknown Source)
    at org.wiztools.restclient.HTTPClientRequestExecuter.execute(HTTPClientRequestExecuter.java:314)
    at org.wiztools.restclient.ui.RESTView$25.run(RESTView.java:1007)

This is not a very helpful message in determining what went wrong and
what to do about it (unless they come and read the bugs and change log
on your site as I did).

I realize that the error is probably due to HttpListener not sending a
content type header in the challenge response.  Unfortunately, this
happens before any user code is executed and there is no way to
specify the content type or headers used at this point.

It is not called out in the HTTP spec that a "401 Unauthorized"
response needs to include a "ContentType" header, and even if it 
did I doubt MS would be racing to update the HttpListener class 
to comply.

I am fairly certain that the body content is empty on this response.
Could RESTClient simply not worry about encoding if there is no
content to decode?

If not, it seems pretty obvious that this is an authentication
challenge.  Could the old style handling possibly be restored in
special cases like this one?

What version of the product are you using? On what operating system?

2.3.2 on Windows XP

Please provide any additional information below.

Original issue reported on code.google.com by shma...@gmail.com on 2 Sep 2010 at 6:24

[GoogleCodeExporter]

Thanks for reporting the issue in such detail. I will work on devising a more 
lenient charset parsing.

Original comment by subwiz on 3 Sep 2010 at 5:00

• Changed state: Accepted

[GoogleCodeExporter]

r476 makes the charset processing more lenient. Now when the charset detail is 
not available in the response header, by default the platform encoding is 
assumed.

Original comment by subwiz on 3 Sep 2010 at 9:16

[GoogleCodeExporter]

Can you try with this build and confirm if it works:

http://dl.dropbox.com/u/2505020/restclient-ui-2.3.3-SNAPSHOT-jar-with-dependenci
es.jar

Original comment by subwiz on 3 Sep 2010 at 9:38

• Changed state: Fixed

[GoogleCodeExporter]

Yes.  That worked!
Thank you for your prompt attention.

I am finding more and more uses for this tool and introducing it to other 
developers who are working with REST web services.  I will be visiting the 
"Make a Donation" link soon and will be encouraging others to do likewise.

Keep up the great work.

Original comment by shma...@gmail.com on 3 Sep 2010 at 2:28

[GoogleCodeExporter]

Thanks for the feedback. Encouraging words like this keeps me going :-)

Original comment by subwiz on 5 Sep 2010 at 1:53

• Changed state: Verified

[GoogleCodeExporter]

This might not be the right place for this comment but I tried out the snapshot 
JAR above and while it fixed the error, the body of the response is not shown. 

Original comment by CyrusOm...@gmail.com on 10 Sep 2010 at 9:15

[GoogleCodeExporter]

You may want to verify if the HTTP server is actually returning a body
with the 401 response.  The HTTP spec only states that "the server
SHOULD include an entity containing an explanation of the error
situation"

The .NET framework library I was dealing with did not return any body
content on a 401 error for missing credentials.  It does return body
content for invalid credentials.  (The latter displays correctly with
the new snapshot.)

I also tested the new snapshot against an IIS site that returns HTML
content as part of a failed authentication in a 401 response, and it
showed up in RESTClient also.

This is why I suspect it might be the server that is not providing the
response, rather than RESTClient not showing it.

Original comment by shma...@gmail.com on 13 Sep 2010 at 2:35