Hi Tamas, I found the cause of your second issue and was able to fix it. Now if there is an entity associated to a DELETE request, it is simply ignored by the client connector and not sent over the wire. The server doesn't notice it at all. Thanks for reporting this. Fix in SVN trunk. 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é : mercredi 17 septembre 2008 17:32 À : [email protected] Objet : Re: Any reason to override 401 to 1002? Hi Jerome, yes, regarding my 1st issue I solved it by registering the HTTP_NxBasic auth scheme just as you described. But in my opinion, this is a little bit to "heavy handed" solution... i have to wait to 1.1 "final" release (or RC2?) to update the dependencies, since we will roll out Nexus 1.1M1 soon (so, no snapshot dependency is desirable). Anyway, it works now just fine (after registering the new auth scheme, we have the desired 401 status instead of 1002 in the ITs). My 2nd issue: I created a little "test case" maven project, attached to the mail. Simply unzip it, and do "$ mvn clean test" and the test-case will simply "hang" (the behaviour we noticed with our IT tests also). I am not sure anymore about my statements in 1st mail, but something is definitely wrong. Try to simply change the restlet version in POM properties section from current 1.1-RC1 back to 1.0.11 and the hang will dissapear! ~t~ On Wed, Sep 17, 2008 at 4:13 PM, Jerome Louvel <[EMAIL PROTECTED]> wrote: 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~ -- Thanks, ~t~
