You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Karl Ostendorf <ka...@t-fs.de> on 2005/11/18 17:27:11 UTC
Problems accessing MapPoint web service after upgrading to 3.0 RC4
Hello,
Our Axis 1.3 SOAP application to access Microsoft's Mappoint web services stopped working after switching to http-client v3RC4 from v3RC3. Specifically we started receiving 401 (Unauthorized) responses under RC4 where in RC3 it just worked. After some debugging I traced the problem down to the HttpMethodDirector.promptForCredentials method lines 856-857. Under RC4 the call to params.getParameter to get the CredentialsProvider returns a null while under RC3 it returns a valid CredentialsProvider.
The java code to access the MapPoint services we generated from the MapPoint WSDL file using WSDL2Java from the Axis 1.3 package. MapPoint authenticates clients via the DIGEST method and because the built-in Axis web client doesn't support DIGEST we followed the documentation and configured Axis to use the commons http-client. Additionally, we are accessing the service via SSL on the staging servers.
I have included the code to reproduce the problem below. If any http-client developer would like to tackle this problem please contact me. I might be able to supply the login credentials to our account in order to spare someone from having to create a new account and uploading the necessary polygon data to the servers.
The code below retrieves a URL for a polygon on the servers.
public String getUrl(int entityId) throws MalformedURLException,
javax.xml.rpc.ServiceException, RemoteException {
log.info("EntityID: " + entityId);
FindServiceLocator flocator = new FindServiceLocator();
FindServiceSoap_PortType finder = flocator.getFindServiceSoap();
((FindServiceSoap_BindingStub) finder).setUsername(this.username);
((FindServiceSoap_BindingStub) finder).setPassword(this.password);
// location
FindFilter filter = new FindFilter();
filter.setEntityTypeName(ENTITY_TYPE);
FindByIDSpecification spec = new FindByIDSpecification();
spec.setDataSourceName(DS_POLYGONS);
spec.setEntityIDs(new int[] { entityId });
spec.setFilter(filter);
FindResults found = finder.findByID(spec);
}
--
T-FS
Karl Ostendorf
Friedrichstr. 30
49610 Quakenbrück
Germany
Mail: karl.ostendorf@t-fs.de
Fon: +49 5431 941215
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0 RC4
Posted by sebb <se...@gmail.com>.
On 19/11/05, sebb <se...@gmail.com> wrote:
> On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Sat, 2005-11-19 at 15:44 +0000, sebb wrote:
> > > On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > > Hello Karl,
> > > >
> > > > Here's the relevant differences between HTTP requests generated using
> > > > 3.0rc3 and 3.0rc4 [1]. The only significant variation I can spot is that
> > > > qop and nc attributes generated by rc4 are not enclosed in quotes. This
> > > > change has been introduced in 3.0rc4 per bug report 36372 [2], which was
> > > > perfectly valid in my opinion. See the original original discussion here
> > >
> > > Bug report 36372 only refers to nc, surely, not qop?
> > >
> > > > [3]. What is actually really fishy here is that the digest challenge
> > >
> > > Note that qop is quoted.
> > >
> >
> > Hi Sebastian,
> >
> > This is how I read the spec [1]
> >
> > The qop attribute of the digest challenge must be enclosed in quotes
> > because it can have multiple comma separated values
> >
> > <quote>
> > challenge = "Digest" digest-challenge
> > ...
> > qop-options = "qop" "=" <"> 1#qop-value <">
> > qop-value = "auth" | "auth-int" | token
> > </quote>
> >
> > Whereas the qop attribute of the digest response implies only one value
> > and therefore it does not have to be enclosed in quotes unless it
> > contains any special characters such as blanks or commas
> >
> > <quote>
> > credentials = "Digest" digest-response
> > ...
> > message-qop = "qop" "=" qop-value
> > </quote>
>
> <quote>
> qop .......
> Note
> that this is a single token, not a quoted list of alternatives as
> in WWW- Authenticate.
> </quote>
>
> The description to me is a bit ambiguous - it does not say clearly
> whether or not the token includes quotes.
>
>
> > So, to me this is clearly a compliance issue with IIS (or whatever it
> > is) server. I personally do not mind making DigestScheme more lenient
> > provided it does not involve dragging in too much of IIS specific hacks.
> > After all, one can simply implement a custom auth scheme and plug it
> > into the HttpClient auth framework
> >
> > Cheers,
> >
> > Oleg
> >
> > [1] http://www.faqs.org/rfcs/rfc2617.html
> >
>
> Which further says:
>
> 3.2.2.1 Request-Digest
>
> If the "qop" value is "auth" or "auth-int":
>
> request-digest = <"> < KD ( H(A1), unq(nonce-value)
> ":" nc-value
> ":" unq(cnonce-value)
> ":" unq(qop-value)
> ":" H(A2)
> ) <">
>
> To me, this suggests that qop-value, nonce-value and cnonce-value are
> quoted, whereas nc-value is not.
>
> We know nonce-value is a quoted string, and cnonce-value = nonce-value.
>
> ==
>
> What I'm suggesting is to try quoting just the "qop" value, and see if
> that works for Karl.
>
> Then check if it all still works for the originator of bug 36372, who
> only mentioned a problem with "nonce-count" in the original bug text.
Just discovered the following code (public domain):
http://www-x.antd.nist.gov/proj/iptel/src/nist-sip/jain-sip/src/gov/nist/javax/sip/header/AuthenticationHeader.java
The setParameter() method treats QOP, CNONCE and NONCE etc the same,
and appears to quote them - nv.setQuotedValue().
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0
RC4
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2005-11-20 at 14:31 +0000, sebb wrote:
> On 20/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Sat, 2005-11-19 at 18:50 +0000, sebb wrote:
> > > > I respectfully disagree. In the HTTP spec quote marks are always
> > > > designated as <">. See request-digest in the example above
> > >
> > > I can't find qop-value defined anywhere as a quoted string, but nor
> > > can I find it defined as a non-quoted string.
> > >
> > > But why does the RFC use the unq() function on qop-value unless it is
> > > a quoted string?
> > >
> > > There are some other examples of the use of unq() - e.g. realm-value -
> > > in each case all of the operands are defined as being quoted strings.
> > >
> >
> > All right. This is how it goes
>
> [snip]
>
> > Hope this makes things clearer
>
> Indeed it does, thanks very much - sorry to put you to the trouble.
> Dunno how I missed the example...
>
No trouble of what so ever
> Why the RFC uses unq() on qop-value is a mystery - the only purpose
> seems to be to confuse readers ;-)
>
Very much so. There are other discrepancies and contradictions in the
RFC2617 we know of
> It will be interesting to find out what combination of quotes is
> accepted by the Map Point service ... if it turns out that quite a few
> servers insist on quotes, then it might be worth making this an
> option.
>
If unquoted qop-value does turn out to be the only reason the digest
response gets rejected, we will consider providing a parameter to always
enclose qop-value in quotes
> >
> > Cheers,
> >
>
> Thanks for your patience.
>
No worries. Thanks for taking interest in HttpClient
Oleg
> S.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0 RC4
Posted by sebb <se...@gmail.com>.
On 20/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sat, 2005-11-19 at 18:50 +0000, sebb wrote:
> > > I respectfully disagree. In the HTTP spec quote marks are always
> > > designated as <">. See request-digest in the example above
> >
> > I can't find qop-value defined anywhere as a quoted string, but nor
> > can I find it defined as a non-quoted string.
> >
> > But why does the RFC use the unq() function on qop-value unless it is
> > a quoted string?
> >
> > There are some other examples of the use of unq() - e.g. realm-value -
> > in each case all of the operands are defined as being quoted strings.
> >
>
> All right. This is how it goes
[snip]
> Hope this makes things clearer
Indeed it does, thanks very much - sorry to put you to the trouble.
Dunno how I missed the example...
Why the RFC uses unq() on qop-value is a mystery - the only purpose
seems to be to confuse readers ;-)
It will be interesting to find out what combination of quotes is
accepted by the Map Point service ... if it turns out that quite a few
servers insist on quotes, then it might be worth making this an
option.
>
> Cheers,
>
Thanks for your patience.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0
RC4
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2005-11-19 at 18:50 +0000, sebb wrote:
> > I respectfully disagree. In the HTTP spec quote marks are always
> > designated as <">. See request-digest in the example above
>
> I can't find qop-value defined anywhere as a quoted string, but nor
> can I find it defined as a non-quoted string.
>
> But why does the RFC use the unq() function on qop-value unless it is
> a quoted string?
>
> There are some other examples of the use of unq() - e.g. realm-value -
> in each case all of the operands are defined as being quoted strings.
>
All right. This is how it goes
qop-value is defined as:
qop-value = "auth" | "auth-int" | token
token is defined as:
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
in fact qop-value per this definition MAY NOT be a quoted string.
This is an example of digest challenge/response given in the spec, section 3.5 [1]
<quote>
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
...
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
</quote>
Note qop attribute in the digest response is not quoted, which makes
perfect sense given its definition in the RFC.
Quoted string is defined in the HTTP spec as [2]:
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR
Hope this makes things clearer
Cheers,
Oleg
[1] http://www.faqs.org/rfcs/rfc2617.html
[2] http://www.faqs.org/rfcs/rfc2616.html
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0 RC4
Posted by sebb <se...@gmail.com>.
On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sat, 2005-11-19 at 18:16 +0000, sebb wrote:
> > On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > On Sat, 2005-11-19 at 15:44 +0000, sebb wrote:
> > > > On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > > > Hello Karl,
> > > > >
> > > > > Here's the relevant differences between HTTP requests generated using
> > > > > 3.0rc3 and 3.0rc4 [1]. The only significant variation I can spot is that
> > > > > qop and nc attributes generated by rc4 are not enclosed in quotes. This
> > > > > change has been introduced in 3.0rc4 per bug report 36372 [2], which was
> > > > > perfectly valid in my opinion. See the original original discussion here
> > > >
> > > > Bug report 36372 only refers to nc, surely, not qop?
> > > >
> > > > > [3]. What is actually really fishy here is that the digest challenge
> > > >
> > > > Note that qop is quoted.
> > > >
> > >
> > > Hi Sebastian,
> > >
> > > This is how I read the spec [1]
> > >
> > > The qop attribute of the digest challenge must be enclosed in quotes
> > > because it can have multiple comma separated values
> > >
> > > <quote>
> > > challenge = "Digest" digest-challenge
> > > ...
> > > qop-options = "qop" "=" <"> 1#qop-value <">
> > > qop-value = "auth" | "auth-int" | token
> > > </quote>
> > >
> > > Whereas the qop attribute of the digest response implies only one value
> > > and therefore it does not have to be enclosed in quotes unless it
> > > contains any special characters such as blanks or commas
> > >
> > > <quote>
> > > credentials = "Digest" digest-response
> > > ...
> > > message-qop = "qop" "=" qop-value
> > > </quote>
> >
> > <quote>
> > qop .......
> > Note
> > that this is a single token, not a quoted list of alternatives as
> > in WWW- Authenticate.
> > </quote>
> >
> > The description to me is a bit ambiguous - it does not say clearly
> > whether or not the token includes quotes.
> >
>
> Sebastian,
>
> I think there's no ambiguity. The syntax rules are very clearly laid out
> in the HTTP spec [1] http://www.faqs.org/rfcs/rfc2616.html
>
> > Which further says:
> >
> > 3.2.2.1 Request-Digest
> >
> > If the "qop" value is "auth" or "auth-int":
> >
> > request-digest = <"> < KD ( H(A1), unq(nonce-value)
> > ":" nc-value
> > ":" unq(cnonce-value)
> > ":" unq(qop-value)
> > ":" H(A2)
> > ) <">
> >
> > To me, this suggests that qop-value, nonce-value and cnonce-value are
> > quoted, whereas nc-value is not.
> >
>
> I respectfully disagree. In the HTTP spec quote marks are always
> designated as <">. See request-digest in the example above
I can't find qop-value defined anywhere as a quoted string, but nor
can I find it defined as a non-quoted string.
But why does the RFC use the unq() function on qop-value unless it is
a quoted string?
There are some other examples of the use of unq() - e.g. realm-value -
in each case all of the operands are defined as being quoted strings.
>
> > We know nonce-value is a quoted string, and cnonce-value = nonce-value.
> >
> > ==
> >
> > What I'm suggesting is to try quoting just the "qop" value, and see if
> > that works for Karl.
> >
> > Then check if it all still works for the originator of bug 36372, who
> > only mentioned a problem with "nonce-count" in the original bug text.
> >
>
> Makes sense to me
>
> Oleg
>
> [1] http://www.faqs.org/rfcs/rfc2616.html
>
> > S.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0
RC4
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2005-11-19 at 18:16 +0000, sebb wrote:
> On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Sat, 2005-11-19 at 15:44 +0000, sebb wrote:
> > > On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > > Hello Karl,
> > > >
> > > > Here's the relevant differences between HTTP requests generated using
> > > > 3.0rc3 and 3.0rc4 [1]. The only significant variation I can spot is that
> > > > qop and nc attributes generated by rc4 are not enclosed in quotes. This
> > > > change has been introduced in 3.0rc4 per bug report 36372 [2], which was
> > > > perfectly valid in my opinion. See the original original discussion here
> > >
> > > Bug report 36372 only refers to nc, surely, not qop?
> > >
> > > > [3]. What is actually really fishy here is that the digest challenge
> > >
> > > Note that qop is quoted.
> > >
> >
> > Hi Sebastian,
> >
> > This is how I read the spec [1]
> >
> > The qop attribute of the digest challenge must be enclosed in quotes
> > because it can have multiple comma separated values
> >
> > <quote>
> > challenge = "Digest" digest-challenge
> > ...
> > qop-options = "qop" "=" <"> 1#qop-value <">
> > qop-value = "auth" | "auth-int" | token
> > </quote>
> >
> > Whereas the qop attribute of the digest response implies only one value
> > and therefore it does not have to be enclosed in quotes unless it
> > contains any special characters such as blanks or commas
> >
> > <quote>
> > credentials = "Digest" digest-response
> > ...
> > message-qop = "qop" "=" qop-value
> > </quote>
>
> <quote>
> qop .......
> Note
> that this is a single token, not a quoted list of alternatives as
> in WWW- Authenticate.
> </quote>
>
> The description to me is a bit ambiguous - it does not say clearly
> whether or not the token includes quotes.
>
Sebastian,
I think there's no ambiguity. The syntax rules are very clearly laid out
in the HTTP spec [1] http://www.faqs.org/rfcs/rfc2616.html
> Which further says:
>
> 3.2.2.1 Request-Digest
>
> If the "qop" value is "auth" or "auth-int":
>
> request-digest = <"> < KD ( H(A1), unq(nonce-value)
> ":" nc-value
> ":" unq(cnonce-value)
> ":" unq(qop-value)
> ":" H(A2)
> ) <">
>
> To me, this suggests that qop-value, nonce-value and cnonce-value are
> quoted, whereas nc-value is not.
>
I respectfully disagree. In the HTTP spec quote marks are always
designated as <">. See request-digest in the example above
> We know nonce-value is a quoted string, and cnonce-value = nonce-value.
>
> ==
>
> What I'm suggesting is to try quoting just the "qop" value, and see if
> that works for Karl.
>
> Then check if it all still works for the originator of bug 36372, who
> only mentioned a problem with "nonce-count" in the original bug text.
>
Makes sense to me
Oleg
[1] http://www.faqs.org/rfcs/rfc2616.html
> S.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0 RC4
Posted by sebb <se...@gmail.com>.
On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sat, 2005-11-19 at 15:44 +0000, sebb wrote:
> > On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > Hello Karl,
> > >
> > > Here's the relevant differences between HTTP requests generated using
> > > 3.0rc3 and 3.0rc4 [1]. The only significant variation I can spot is that
> > > qop and nc attributes generated by rc4 are not enclosed in quotes. This
> > > change has been introduced in 3.0rc4 per bug report 36372 [2], which was
> > > perfectly valid in my opinion. See the original original discussion here
> >
> > Bug report 36372 only refers to nc, surely, not qop?
> >
> > > [3]. What is actually really fishy here is that the digest challenge
> >
> > Note that qop is quoted.
> >
>
> Hi Sebastian,
>
> This is how I read the spec [1]
>
> The qop attribute of the digest challenge must be enclosed in quotes
> because it can have multiple comma separated values
>
> <quote>
> challenge = "Digest" digest-challenge
> ...
> qop-options = "qop" "=" <"> 1#qop-value <">
> qop-value = "auth" | "auth-int" | token
> </quote>
>
> Whereas the qop attribute of the digest response implies only one value
> and therefore it does not have to be enclosed in quotes unless it
> contains any special characters such as blanks or commas
>
> <quote>
> credentials = "Digest" digest-response
> ...
> message-qop = "qop" "=" qop-value
> </quote>
<quote>
qop .......
Note
that this is a single token, not a quoted list of alternatives as
in WWW- Authenticate.
</quote>
The description to me is a bit ambiguous - it does not say clearly
whether or not the token includes quotes.
> So, to me this is clearly a compliance issue with IIS (or whatever it
> is) server. I personally do not mind making DigestScheme more lenient
> provided it does not involve dragging in too much of IIS specific hacks.
> After all, one can simply implement a custom auth scheme and plug it
> into the HttpClient auth framework
>
> Cheers,
>
> Oleg
>
> [1] http://www.faqs.org/rfcs/rfc2617.html
>
Which further says:
3.2.2.1 Request-Digest
If the "qop" value is "auth" or "auth-int":
request-digest = <"> < KD ( H(A1), unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
":" H(A2)
) <">
To me, this suggests that qop-value, nonce-value and cnonce-value are
quoted, whereas nc-value is not.
We know nonce-value is a quoted string, and cnonce-value = nonce-value.
==
What I'm suggesting is to try quoting just the "qop" value, and see if
that works for Karl.
Then check if it all still works for the originator of bug 36372, who
only mentioned a problem with "nonce-count" in the original bug text.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0
RC4
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2005-11-19 at 15:44 +0000, sebb wrote:
> On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > Hello Karl,
> >
> > Here's the relevant differences between HTTP requests generated using
> > 3.0rc3 and 3.0rc4 [1]. The only significant variation I can spot is that
> > qop and nc attributes generated by rc4 are not enclosed in quotes. This
> > change has been introduced in 3.0rc4 per bug report 36372 [2], which was
> > perfectly valid in my opinion. See the original original discussion here
>
> Bug report 36372 only refers to nc, surely, not qop?
>
> > [3]. What is actually really fishy here is that the digest challenge
>
> Note that qop is quoted.
>
Hi Sebastian,
This is how I read the spec [1]
The qop attribute of the digest challenge must be enclosed in quotes
because it can have multiple comma separated values
<quote>
challenge = "Digest" digest-challenge
...
qop-options = "qop" "=" <"> 1#qop-value <">
qop-value = "auth" | "auth-int" | token
</quote>
Whereas the qop attribute of the digest response implies only one value
and therefore it does not have to be enclosed in quotes unless it
contains any special characters such as blanks or commas
<quote>
credentials = "Digest" digest-response
...
message-qop = "qop" "=" qop-value
</quote>
So, to me this is clearly a compliance issue with IIS (or whatever it
is) server. I personally do not mind making DigestScheme more lenient
provided it does not involve dragging in too much of IIS specific hacks.
After all, one can simply implement a custom auth scheme and plug it
into the HttpClient auth framework
Cheers,
Oleg
[1] http://www.faqs.org/rfcs/rfc2617.html
> > sent by the server does not look like those usually generated by IIS
> > [4]. Even though the server identifies itself as IIS 6.0 it is likely to
> > be something else. So, overall this appears like a server side problem
>
> Are you sure it's not as per [4]?
>
> > to me. To test this assumption consider tweaking the source code here
> > [5], recompile HttpClient and see if that makes any difference
> >
> > Hope this helps
> >
> > Oleg
> >
> > [1]
> > 2c2
> > < header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc3[\r][\n]"
> > ---
> > > header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc4[\r][\n]"
> > 23c23
> > < header << "Date: Sat, 19 Nov 2005 10:13:17 GMT[\r][\n]"
> > ---
> > > header << "Date: Sat, 19 Nov 2005 10:13:41 GMT[\r][\n]"
> > 27c27
> > < header << "WWW-Authenticate: Digest qop="auth", realm="MapPoint",
> > nonce="058ce1c31bf6f30f7915932311001c0969ae245318c3a877671ae55744a3"[\r][\n]"
> > ---
> > > header << "WWW-Authenticate: Digest qop="auth", realm="MapPoint",
> > nonce="4da02d5cf00457a7122593231100904c92c9d9832c796c2a81bf3b8638ec"[\r][\n]"
> > 30c30
> > < header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc3[\r][\n]"
> > ---
> > > header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc4[\r][\n]"
> > 40c40
> > < header >> "Authorization: Digest username="107768", realm="MapPoint",
> > nonce="058ce1c31bf6f30f7915932311001c0969ae245318c3a877671ae55744a3",
> > uri="/Find-30/FindService.asmx",
> > response="a900983ea4ed8aa867ff97968c474b17", qop="auth", nc="00000001",
> > cnonce="e67d91e647da701da45ae7f100a61341"[\r][\n]"
> > ---
> > > header >> "Authorization: Digest username="107768", realm="MapPoint",
> > nonce="4da02d5cf00457a7122593231100904c92c9d9832c796c2a81bf3b8638ec",
> > uri="/Find-30/FindService.asmx",
> > response="5e2070488ae46efa833147acfa0f09a8", qop=auth, nc=00000001,
> > cnonce="f91a562bc4cd724171b8f50545cbb8a4"[\r][\n]"
> > 50,51c50,52
> > < header << "HTTP/1.1 200 OK[\r][\n]"
> > < header << "Date: Sat, 19 Nov 2005 10:13:18 GMT[\r][\n]"
> > ---
> > > header << "HTTP/1.1 401 Unauthorized[\r][\n]"
> > > header << "Connection: close[\r][\n]"
> > > header << "Date: Sat, 19 Nov 2005 10:13:42 GMT[\r][\n]"
> > 55,60c56,57
> >
> > [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=36372
> >
> > [3]
> > http://www.mail-archive.com/httpclient-user@jakarta.apache.org/msg01176.html
> >
> > [4]
> > http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/717b450c-f4a0-4cc9-86f4-cc0633aae5f9.mspx
>
> This seems to say that qop = "auth" | "auth-int" | "auth-conf".
>
> Also, rfc2617 says that the qop response should be chosen from one of
> the alternatives present in the WWW-Authenticate header - in which qop
> is quoted.
>
> So perhaps the problem is that both qop and nc have been "dequoted" -
> whereas as far as I can see qop should remain a quoted string
>
> If qop quoting _can_ vary, then the quoting strategy could perhaps be
> taken from the WWW-Authenticate header?
>
> Might be worth trying just quoting qop and seeing if this solves the problem...
>
> HTH.
>
> S.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0 RC4
Posted by sebb <se...@gmail.com>.
On 19/11/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> Hello Karl,
>
> Here's the relevant differences between HTTP requests generated using
> 3.0rc3 and 3.0rc4 [1]. The only significant variation I can spot is that
> qop and nc attributes generated by rc4 are not enclosed in quotes. This
> change has been introduced in 3.0rc4 per bug report 36372 [2], which was
> perfectly valid in my opinion. See the original original discussion here
Bug report 36372 only refers to nc, surely, not qop?
> [3]. What is actually really fishy here is that the digest challenge
Note that qop is quoted.
> sent by the server does not look like those usually generated by IIS
> [4]. Even though the server identifies itself as IIS 6.0 it is likely to
> be something else. So, overall this appears like a server side problem
Are you sure it's not as per [4]?
> to me. To test this assumption consider tweaking the source code here
> [5], recompile HttpClient and see if that makes any difference
>
> Hope this helps
>
> Oleg
>
> [1]
> 2c2
> < header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc3[\r][\n]"
> ---
> > header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc4[\r][\n]"
> 23c23
> < header << "Date: Sat, 19 Nov 2005 10:13:17 GMT[\r][\n]"
> ---
> > header << "Date: Sat, 19 Nov 2005 10:13:41 GMT[\r][\n]"
> 27c27
> < header << "WWW-Authenticate: Digest qop="auth", realm="MapPoint",
> nonce="058ce1c31bf6f30f7915932311001c0969ae245318c3a877671ae55744a3"[\r][\n]"
> ---
> > header << "WWW-Authenticate: Digest qop="auth", realm="MapPoint",
> nonce="4da02d5cf00457a7122593231100904c92c9d9832c796c2a81bf3b8638ec"[\r][\n]"
> 30c30
> < header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc3[\r][\n]"
> ---
> > header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc4[\r][\n]"
> 40c40
> < header >> "Authorization: Digest username="107768", realm="MapPoint",
> nonce="058ce1c31bf6f30f7915932311001c0969ae245318c3a877671ae55744a3",
> uri="/Find-30/FindService.asmx",
> response="a900983ea4ed8aa867ff97968c474b17", qop="auth", nc="00000001",
> cnonce="e67d91e647da701da45ae7f100a61341"[\r][\n]"
> ---
> > header >> "Authorization: Digest username="107768", realm="MapPoint",
> nonce="4da02d5cf00457a7122593231100904c92c9d9832c796c2a81bf3b8638ec",
> uri="/Find-30/FindService.asmx",
> response="5e2070488ae46efa833147acfa0f09a8", qop=auth, nc=00000001,
> cnonce="f91a562bc4cd724171b8f50545cbb8a4"[\r][\n]"
> 50,51c50,52
> < header << "HTTP/1.1 200 OK[\r][\n]"
> < header << "Date: Sat, 19 Nov 2005 10:13:18 GMT[\r][\n]"
> ---
> > header << "HTTP/1.1 401 Unauthorized[\r][\n]"
> > header << "Connection: close[\r][\n]"
> > header << "Date: Sat, 19 Nov 2005 10:13:42 GMT[\r][\n]"
> 55,60c56,57
>
> [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=36372
>
> [3]
> http://www.mail-archive.com/httpclient-user@jakarta.apache.org/msg01176.html
>
> [4]
> http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/717b450c-f4a0-4cc9-86f4-cc0633aae5f9.mspx
This seems to say that qop = "auth" | "auth-int" | "auth-conf".
Also, rfc2617 says that the qop response should be chosen from one of
the alternatives present in the WWW-Authenticate header - in which qop
is quoted.
So perhaps the problem is that both qop and nc have been "dequoted" -
whereas as far as I can see qop should remain a quoted string
If qop quoting _can_ vary, then the quoting strategy could perhaps be
taken from the WWW-Authenticate header?
Might be worth trying just quoting qop and seeing if this solves the problem...
HTH.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0
RC4
Posted by Karl Ostendorf <ka...@t-fs.de>.
Hello Oleg,
Thanks for pointing me in the right direction. It looks like I will have to tweak the source to get MapPoint working.
What I didn't mention is that in addition to the main MapPoint WSDL there is also an additional web service with a separate WSDL, the Customer Data Service for uploading and downloading data to the service, that did not work under 3.0 RC3 but did start working under RC4 (same problem: 401s). Your comment that the server does not look like IIS but advertises itself as such sounds interesting and I suspect that their use of a reverse proxy is mucking things up.
Karl
--
T-FS
Karl Ostendorf
Friedrichstr. 30
49610 Quakenbrück
Mail: karl.ostendorf@t-fs.de
Fon: +49 5431 941215
Oleg Kalnichevski wrote:
> Hello Karl,
>
> Here's the relevant differences between HTTP requests generated using
> 3.0rc3 and 3.0rc4 [1]. The only significant variation I can spot is that
> qop and nc attributes generated by rc4 are not enclosed in quotes. This
> change has been introduced in 3.0rc4 per bug report 36372 [2], which was
> perfectly valid in my opinion. See the original original discussion here
> [3]. What is actually really fishy here is that the digest challenge
> sent by the server does not look like those usually generated by IIS
> [4]. Even though the server identifies itself as IIS 6.0 it is likely to
> be something else. So, overall this appears like a server side problem
> to me. To test this assumption consider tweaking the source code here
> [5], recompile HttpClient and see if that makes any difference
>
> Hope this helps
>
> Oleg
>
> [1]
> 2c2
> < header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc3[\r][\n]"
> ---
>
>>header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc4[\r][\n]"
>
> 23c23
> < header << "Date: Sat, 19 Nov 2005 10:13:17 GMT[\r][\n]"
> ---
>
>>header << "Date: Sat, 19 Nov 2005 10:13:41 GMT[\r][\n]"
>
> 27c27
> < header << "WWW-Authenticate: Digest qop="auth", realm="MapPoint",
> nonce="058ce1c31bf6f30f7915932311001c0969ae245318c3a877671ae55744a3"[\r][\n]"
> ---
>
>>header << "WWW-Authenticate: Digest qop="auth", realm="MapPoint",
>
> nonce="4da02d5cf00457a7122593231100904c92c9d9832c796c2a81bf3b8638ec"[\r][\n]"
> 30c30
> < header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc3[\r][\n]"
> ---
>
>>header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc4[\r][\n]"
>
> 40c40
> < header >> "Authorization: Digest username="107768", realm="MapPoint",
> nonce="058ce1c31bf6f30f7915932311001c0969ae245318c3a877671ae55744a3",
> uri="/Find-30/FindService.asmx",
> response="a900983ea4ed8aa867ff97968c474b17", qop="auth", nc="00000001",
> cnonce="e67d91e647da701da45ae7f100a61341"[\r][\n]"
> ---
>
>>header >> "Authorization: Digest username="107768", realm="MapPoint",
>
> nonce="4da02d5cf00457a7122593231100904c92c9d9832c796c2a81bf3b8638ec",
> uri="/Find-30/FindService.asmx",
> response="5e2070488ae46efa833147acfa0f09a8", qop=auth, nc=00000001,
> cnonce="f91a562bc4cd724171b8f50545cbb8a4"[\r][\n]"
> 50,51c50,52
> < header << "HTTP/1.1 200 OK[\r][\n]"
> < header << "Date: Sat, 19 Nov 2005 10:13:18 GMT[\r][\n]"
> ---
>
>>header << "HTTP/1.1 401 Unauthorized[\r][\n]"
>>header << "Connection: close[\r][\n]"
>>header << "Date: Sat, 19 Nov 2005 10:13:42 GMT[\r][\n]"
>
> 55,60c56,57
>
> [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=36372
>
> [3]
> http://www.mail-archive.com/httpclient-user@jakarta.apache.org/msg01176.html
>
> [4]
> http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/717b450c-f4a0-4cc9-86f4-cc0633aae5f9.mspx
>
> [5]
> http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/auth/DigestScheme.html#493
>
> On Sat, 2005-11-19 at 11:24 +0100, Karl Ostendorf wrote:
>
>>Hello Oleg,
>>
>>Attached you will find two wire protocols, one using 3.0 RC3 where the call is successful and one using 3.0 RC4 where it fails.
>>
>>Karl
>>
>>--
>>T-FS
>>
>>Karl Ostendorf
>>Friedrichstr. 30
>>49610 Quakenbrück
>>
>>Mail: karl.ostendorf@t-fs.de
>>Fon: +49 5431 941215
>>
>
>
>
Re: Problems accessing MapPoint web service after upgrading to 3.0
RC4
Posted by Oleg Kalnichevski <ol...@apache.org>.
Hello Karl,
Here's the relevant differences between HTTP requests generated using
3.0rc3 and 3.0rc4 [1]. The only significant variation I can spot is that
qop and nc attributes generated by rc4 are not enclosed in quotes. This
change has been introduced in 3.0rc4 per bug report 36372 [2], which was
perfectly valid in my opinion. See the original original discussion here
[3]. What is actually really fishy here is that the digest challenge
sent by the server does not look like those usually generated by IIS
[4]. Even though the server identifies itself as IIS 6.0 it is likely to
be something else. So, overall this appears like a server side problem
to me. To test this assumption consider tweaking the source code here
[5], recompile HttpClient and see if that makes any difference
Hope this helps
Oleg
[1]
2c2
< header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc3[\r][\n]"
---
> header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc4[\r][\n]"
23c23
< header << "Date: Sat, 19 Nov 2005 10:13:17 GMT[\r][\n]"
---
> header << "Date: Sat, 19 Nov 2005 10:13:41 GMT[\r][\n]"
27c27
< header << "WWW-Authenticate: Digest qop="auth", realm="MapPoint",
nonce="058ce1c31bf6f30f7915932311001c0969ae245318c3a877671ae55744a3"[\r][\n]"
---
> header << "WWW-Authenticate: Digest qop="auth", realm="MapPoint",
nonce="4da02d5cf00457a7122593231100904c92c9d9832c796c2a81bf3b8638ec"[\r][\n]"
30c30
< header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc3[\r][\n]"
---
> header >> "User-Agent: Jakarta Commons-HttpClient/3.0-rc4[\r][\n]"
40c40
< header >> "Authorization: Digest username="107768", realm="MapPoint",
nonce="058ce1c31bf6f30f7915932311001c0969ae245318c3a877671ae55744a3",
uri="/Find-30/FindService.asmx",
response="a900983ea4ed8aa867ff97968c474b17", qop="auth", nc="00000001",
cnonce="e67d91e647da701da45ae7f100a61341"[\r][\n]"
---
> header >> "Authorization: Digest username="107768", realm="MapPoint",
nonce="4da02d5cf00457a7122593231100904c92c9d9832c796c2a81bf3b8638ec",
uri="/Find-30/FindService.asmx",
response="5e2070488ae46efa833147acfa0f09a8", qop=auth, nc=00000001,
cnonce="f91a562bc4cd724171b8f50545cbb8a4"[\r][\n]"
50,51c50,52
< header << "HTTP/1.1 200 OK[\r][\n]"
< header << "Date: Sat, 19 Nov 2005 10:13:18 GMT[\r][\n]"
---
> header << "HTTP/1.1 401 Unauthorized[\r][\n]"
> header << "Connection: close[\r][\n]"
> header << "Date: Sat, 19 Nov 2005 10:13:42 GMT[\r][\n]"
55,60c56,57
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=36372
[3]
http://www.mail-archive.com/httpclient-user@jakarta.apache.org/msg01176.html
[4]
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/717b450c-f4a0-4cc9-86f4-cc0633aae5f9.mspx
[5]
http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/auth/DigestScheme.html#493
On Sat, 2005-11-19 at 11:24 +0100, Karl Ostendorf wrote:
> Hello Oleg,
>
> Attached you will find two wire protocols, one using 3.0 RC3 where the call is successful and one using 3.0 RC4 where it fails.
>
> Karl
>
> --
> T-FS
>
> Karl Ostendorf
> Friedrichstr. 30
> 49610 Quakenbrück
>
> Mail: karl.ostendorf@t-fs.de
> Fon: +49 5431 941215
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Problems accessing MapPoint web service after upgrading to 3.0
RC4
Posted by Karl Ostendorf <ka...@t-fs.de>.
Hello Oleg,
Attached you will find two wire protocols, one using 3.0 RC3 where the call is successful and one using 3.0 RC4 where it fails.
Karl
--
T-FS
Karl Ostendorf
Friedrichstr. 30
49610 Quakenbr�ck
Mail: karl.ostendorf@t-fs.de
Fon: +49 5431 941215
Oleg Kalnichevski wrote:
> On Fri, 2005-11-18 at 17:27 +0100, Karl Ostendorf wrote:
>
>>Hello,
>>
>>Our Axis 1.3 SOAP application to access Microsoft's Mappoint web services stopped working after switching to http-client v3RC4 from v3RC3. Specifically we started receiving 401 (Unauthorized) responses under RC4 where in RC3 it just worked. After some debugging I traced the problem down to the HttpMethodDirector.promptForCredentials method lines 856-857. Under RC4 the call to params.getParameter to get the CredentialsProvider returns a null while under RC3 it returns a valid CredentialsProvider.
>>
>>The java code to access the MapPoint services we generated from the MapPoint WSDL file using WSDL2Java from the Axis 1.3 package. MapPoint authenticates clients via the DIGEST method and because the built-in Axis web client doesn't support DIGEST we followed the documentation and configured Axis to use the commons http-client. Additionally, we are accessing the service via SSL on the staging servers.
>>
>>
>>I have included the code to reproduce the problem below. If any http-client developer would like to tackle this problem please contact me. I might be able to supply the login credentials to our account in order to spare someone from having to create a new account and uploading the necessary polygon data to the servers.
>>
>
>
> Karl,
>
> Please send me the wire log [1] generated with 3.0rc4 that exhibits the
> problem and with 3.0rc4 that does not
>
> Oleg
>
> [1] http://jakarta.apache.org/commons/httpclient/logging.html
>
>
>
>>The code below retrieves a URL for a polygon on the servers.
>>
>>
>> public String getUrl(int entityId) throws MalformedURLException,
>> javax.xml.rpc.ServiceException, RemoteException {
>>
>> log.info("EntityID: " + entityId);
>>
>> FindServiceLocator flocator = new FindServiceLocator();
>> FindServiceSoap_PortType finder = flocator.getFindServiceSoap();
>> ((FindServiceSoap_BindingStub) finder).setUsername(this.username);
>> ((FindServiceSoap_BindingStub) finder).setPassword(this.password);
>>
>> // location
>> FindFilter filter = new FindFilter();
>> filter.setEntityTypeName(ENTITY_TYPE);
>> FindByIDSpecification spec = new FindByIDSpecification();
>> spec.setDataSourceName(DS_POLYGONS);
>> spec.setEntityIDs(new int[] { entityId });
>> spec.setFilter(filter);
>>
>> FindResults found = finder.findByID(spec);
>>
>> }
>>
>
>
Re: Problems accessing MapPoint web service after upgrading to 3.0
RC4
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2005-11-18 at 17:27 +0100, Karl Ostendorf wrote:
> Hello,
>
> Our Axis 1.3 SOAP application to access Microsoft's Mappoint web services stopped working after switching to http-client v3RC4 from v3RC3. Specifically we started receiving 401 (Unauthorized) responses under RC4 where in RC3 it just worked. After some debugging I traced the problem down to the HttpMethodDirector.promptForCredentials method lines 856-857. Under RC4 the call to params.getParameter to get the CredentialsProvider returns a null while under RC3 it returns a valid CredentialsProvider.
>
> The java code to access the MapPoint services we generated from the MapPoint WSDL file using WSDL2Java from the Axis 1.3 package. MapPoint authenticates clients via the DIGEST method and because the built-in Axis web client doesn't support DIGEST we followed the documentation and configured Axis to use the commons http-client. Additionally, we are accessing the service via SSL on the staging servers.
>
>
> I have included the code to reproduce the problem below. If any http-client developer would like to tackle this problem please contact me. I might be able to supply the login credentials to our account in order to spare someone from having to create a new account and uploading the necessary polygon data to the servers.
>
Karl,
Please send me the wire log [1] generated with 3.0rc4 that exhibits the
problem and with 3.0rc4 that does not
Oleg
[1] http://jakarta.apache.org/commons/httpclient/logging.html
> The code below retrieves a URL for a polygon on the servers.
>
>
> public String getUrl(int entityId) throws MalformedURLException,
> javax.xml.rpc.ServiceException, RemoteException {
>
> log.info("EntityID: " + entityId);
>
> FindServiceLocator flocator = new FindServiceLocator();
> FindServiceSoap_PortType finder = flocator.getFindServiceSoap();
> ((FindServiceSoap_BindingStub) finder).setUsername(this.username);
> ((FindServiceSoap_BindingStub) finder).setPassword(this.password);
>
> // location
> FindFilter filter = new FindFilter();
> filter.setEntityTypeName(ENTITY_TYPE);
> FindByIDSpecification spec = new FindByIDSpecification();
> spec.setDataSourceName(DS_POLYGONS);
> spec.setEntityIDs(new int[] { entityId });
> spec.setFilter(filter);
>
> FindResults found = finder.findByID(spec);
>
> }
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org