Hi Jerome, thanks a lot for fixes! I hope it will be released soon enough to make it into Nexus 1.1M1 (planned for end of this week, or early next week).
~t~ On Mon, Sep 22, 2008 at 5:55 PM, Jerome Louvel <[EMAIL PROTECTED]>wrote: > 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 > Noelios Technologies ~ Co-founder ~ 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 >> Noelios Technologies ~ Co-founder ~ 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~ > -- Thanks, ~t~
