Martin First off I would point out that Dydra has terrible support for HTTP authentication
1 - https://getsatisfaction.com/dydra/topics/basic_digest_http_authentication_i s_not_supported 2 - https://getsatisfaction.com/dydra/topics/most_http_authentication_method_do nt_work_using_net These basically boil down to the same bug which is that they don't actually do HTTP Challenge Response properly unless you specify a machine-readable MIME type in the Accept header, the problem is that for SPARQL Updates you aren't expecting a response so you send */* as the Accept header (if you include anything) and they give you a 200 OK with the HTML login page rather than 401 Unauthorized. I filed these 2 years ago and they are still unresolved, I gave up trying to persuade them to behave sensibly as I had many other problems with their services. You didn't include the response part of the HTTP trace but I assume this is what is happening in your case. On the subject of actually solving your issue you can get ARQ to do pre-emptive authentication by using the PreemptiveBasicAuthenticator as a decorator e.g. updateProcess.setAuthenticator(new PreemptiveBasicAuthenticator(new SimpleAuthenticator("username", "password".toCharArray()))); Re: the specs, the spec says MAY which allows the client the option of behaving that way which means a client is not required to do so. Jena makes this opt in behavior which the user must explicitly turn on for several reasons: 1 - It is less secure because if used incorrectly can expose credentials to servers that don't require them 2 - It only works for basic authentication and is not usable with other authentication methods e.g. digest authentication 3 - It requires the user to know whether the remote server would normally send a 401 or 407 challenge The old behavior only applied to queries anyway (updates never had any auth support until 2.10.1 and then it was broken anyway hence the rewrite) and the query behavior was broken in that it only supported basic authentication for 401 challenges and didn't support proxy auth (407 challenges) or any other auth methods. See http://jena.staging.apache.org/documentation/query/http-auth.html for the staged documentation for the new functionality. Rob On 7/15/13 1:23 AM, "Martynas Jusevičius" <marty...@graphity.org> wrote: >Thanks Arthur. I was watching that thread, but I don't think the >current Jena's behavior is correct. >HTTP is not the only (or even main) RFC covering HTTP authentication. >I'm referring to RFC 2617 "HTTP Authentication: Basic and Digest >Access Authentication", which states that: > > A client MAY preemptively send the corresponding Authorization >header with requests for resources in that space without receipt of >another challenge from the server. > >In this case I'm not controlling the server but I know it is expecting >authentication -- so why the extra round-trip with the challenge? >I think there has to be a way to send authorization preemptively. Rob, >what was wrong with the previous behavior? > >Martynas > >On Mon, Jul 15, 2013 at 9:33 AM, Arthur Vaïsse-Lesteven ><arthurvai...@yahoo.fr> wrote: >> Hi, >> >> I was in trouble with the same problem few time ago. >> Refering to this thread : >>https://mail-archives.apache.org/mod_mbox/jena-users/201306.mbox/browser >> you can see that the default behaviour cinsist in send the request >>without credentials, and if the distante server/proxy return an error >>code for authentication required, then a second request including >>credentials is sended. >> >> Rob Vesse explained me that this behaviour is described in the HTTP 1.1 >>specification (RFC 2616 - http://www.ietf.org/rfc/rfc2616.txt). >> >> This piece of code, present in my servor work on my computer. It >>challenges the HTTP client to add credentials for basic authentication. >> >> protected void doPost( HttpServletRequest req, HttpServletResponse resp >>){ >> [...] >> //no credentials, or only username or password, but not both. >> if( credentials == null || credentials.length != 2){ >> resp.addHeader("WWW-Authenticate", "BASIC realm=\"realm\""); >> resp.sendError(HttpServletResponse.SC_UNAUTHORIZED); >> } >> [...] >> >> Hope it will help you. >> >> VAÏSSE-LESTEVEN Arthur. >> >> >> <marty...@graphity.org> wrote: >>> Hey, >>> >>> I know changes were introduced (and bugs fixed) in this area, but I'm >>> having trouble getting update requests to work with HTTP Basic >>> authentication. >>> >>> This code should send authenticated INSERT to Dydra: >>> >>> UpdateRequest update = UpdateFactory.create(uString); >>> UpdateProcessRemote updateProcess = (UpdateProcessRemote) >>> UpdateExecutionFactory.createRemote(update, >>> "http://dydra.com/user/mycompany/sparql";); >>> updateProcess.setAuthentication("x...@yyy.com", >>>"zzz".toCharArray()); >>> updateProcess.execute(); >>> >>> and logs the following output: >>> >>> 00:56:45,972 DEBUG DefaultClientConnectionOperator:177 - Connecting to >>> dydra.com:80 >>> 00:56:46,000 DEBUG RequestAddCookies:132 - CookieSpec selected: >>>best-match >>> 00:56:46,016 DEBUG RequestAuthCache:78 - Auth cache not set in the >>>context >>> 00:56:46,016 DEBUG RequestTargetAuthentication:78 - Target auth state: >>> UNCHALLENGED >>> 00:56:46,017 DEBUG RequestProxyAuthentication:87 - Proxy auth state: >>> UNCHALLENGED >>> 00:56:46,017 DEBUG SystemDefaultHttpClient:715 - Attempt 1 to execute >>>request >>> 00:56:46,018 DEBUG DefaultClientConnection:269 - Sending request: POST >>> /user/mycompany/sparql HTTP/1.1 >>> 00:56:46,018 DEBUG wire:63 - >> "POST /user/mycompany/sparql >>>HTTP/1.1[\r][\n]" >>> 00:56:46,020 DEBUG wire:63 - >> "Content-Length: 175[\r][\n]" >>> 00:56:46,020 DEBUG wire:63 - >> "Content-Type: >>> application/sparql-update[\r][\n]" >>> 00:56:46,020 DEBUG wire:63 - >> "Host: dydra.com[\r][\n]" >>> 00:56:46,021 DEBUG wire:63 - >> "Connection: Keep-Alive[\r][\n]" >>> 00:56:46,021 DEBUG wire:63 - >> "User-Agent: Apache-HttpClient/4.2.3 >>> (java 1.5)[\r][\n]" >>> 00:56:46,021 DEBUG wire:63 - >> "[\r][\n]" >>> 00:56:46,021 DEBUG headers:273 - >> POST /user/mycompany/sparql >>>HTTP/1.1 >>> 00:56:46,021 DEBUG headers:276 - >> Content-Length: 175 >>> 00:56:46,022 DEBUG headers:276 - >> Content-Type: >>>application/sparql-update >>> 00:56:46,022 DEBUG headers:276 - >> Host: dydra.com >>> 00:56:46,022 DEBUG headers:276 - >> Connection: Keep-Alive >>> 00:56:46,022 DEBUG headers:276 - >> User-Agent: >>> Apache-HttpClient/4.2.3 (java 1.5) >>> 00:56:46,023 DEBUG wire:63 - >> "INSERT DATA {[\n]" >>> >>> It does not seem that the Authorization header is present in the >>>request? >>> >>> Martynas >>> graphityhq.com
