Hi Tamas, Thanks for reporting those issues. I've made some changes in SVN trunk so that unknown challenge schemes should hide anymore the actual response status received. Let me know if it doesn't work. However, in order to make your solution fully work, you'll have to declare a proper AuthenticationHelper for HTTP_NxBASIC scheme and register it with the Restlet engine. Since Restlet 1.1, we now support pluggagle authentication helpers for extensibility purpose. See OAuth extension for an example on how to do that (basically adding a META-INF/services/com.noelios.restlet.AuthenticationHelper file pointing to an AuthenticationHelper subclass). In your case, you could probably directly reuse the com.noelios.restlet.authentication.HttpBasicHelper class. -- Regarding DELETE, the spec doesn't seem to forbid passing an entity: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7 I'm not sure to understand how you got into this state in a first place. Could you describe your scenario a bit more? Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com
_____ De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Tamás Cservenák Envoyé : mardi 16 septembre 2008 19:29 À : [email protected] Objet : Any reason to override 401 to 1002? Hello there, i am seeking for any answer on reason of overriding the 401 HTTP status code to 1002 in the Restlet Client. We are using the HTTP Restlet Client (1.1-RC1) in the IT tests of Sonatype Nexus, and after the change (from 1.0.x line) we noticed a bunch of IT failures. As it turned out, it boils down to the reason that restlet Client simply "says" 1002 instead of expected 401. The reason: "java.lang.IllegalArgumentException: Challenge scheme HTTP_NxBASIC not supported by the Restlet engine." Because of ExtJS + HTTP Basic issues (browsers "stealing" auth) we changed the auth scheme -- actually renamed the Basic to NxBasic -- only to avoid browser login pop-up. But the 1.1-RC1 client simply overrides (HttpClientConverter, line 471) the 401 status with 1002, since Nexus responded with Challenge scheme "NxBasic". Any way to fix this at Client side, to have the _real_ response and not information about the fact that client is not supporting something? ;) --- Also, we discovered another bug (?): Our ITs were always (was not checking for HTTP Method in question) invoking request.setEntity(aValue) on Requests processed with Restlet Client, and it was working fine with Client 1.0.x. Now, with 1.1-RC1, something changed, and it produces strange requests (i may say malformed ones). Like for example this (HttpClient wire log): 2008-09-15 21:52:33.280 DEBUG [main:] - httpclient.wire.header: >> "DELETE /nexus/service/local/repo_targets/11c678c3265 HTTP/1.1[\r][\n]" 2008-09-15 21:52:33.280 DEBUG [main:] - org.apache.commons.httpclient.HttpMethodBase: Adding Host request header 2008-09-15 21:52:33.280 DEBUG [main:] - httpclient.wire.header: >> "User-Agent: Noelios-Restlet-Engine/1.1.rc1[\r][\n]" 2008-09-15 21:52:33.280 DEBUG [main:] - httpclient.wire.header: >> "Accept: */*[\r][\n]" 2008-09-15 21:52:33.280 DEBUG [main:] - httpclient.wire.header: >> "Content-Type: application/json; charset=UTF-8[\r][\n]" 2008-09-15 21:52:33.280 DEBUG [main:] - httpclient.wire.header: >> "Content-Length: 106[\r][\n]" 2008-09-15 21:52:33.281 DEBUG [main:] - httpclient.wire.header: >> "Host: localhost:8087[\r][\n]" 2008-09-15 21:52:33.281 DEBUG [main:] - httpclient.wire.header: >> "[\r][\n]" So, it is a DELETE, with content type and content length set (!). Not to mention, that it confused the restlet (also 1.1-RC1) on server side, and caused both to simply wait for each other it seems (the IT Client sent only one CR+LF, while the server side restlet was waiting for two (it seems it was waiting for body?), since no body was present, but content length was there)... so, finally, both timeouted and declared that other party was having some HTTP issues. I mean, i am aware that it was possibly an API "misuse" (setting the entity of the Request with DELETE method), but it was working in 1.0.x line just perfect. What happened? We fixed this issues by checking the method in question, but IMO this should be handled by Request/Client and not by users. Why do we have then restlet abstraction at all when the user should "watch" for HTTP Message correctness then? -- Thanks, ~t~
