Am 2019-03-29 um 22:07 schrieb Mark Thomas:
On 29/03/2019 12:28, Michael Osipov wrote:
Am 2019-03-29 um 12:14 schrieb Mark Thomas:
On 28/03/2019 15:14, Osipov, Michael wrote:
Hi folks,
right away, I don't know whether it is us (Tomcat) or curl. I'd lke to
narrow down the cause.
It seems to be related to the use of kerberos. I don't see any errors
when I provide the user name and password on the command line.
I wonder how because it is only one roundtrip..
* Server auth using Negotiate with user ''
The above looks odd. Shouldn't that show the user name being used?
This is a curl shortcoming, but not a bug. It simply indicates that no
user (-u :, known issue #10) has been provided. It does not obtain the
GSS name from the default credential.
I've got some a Kerberos test environment in some VMs. I'll spin that up
and see if I can reproduce the issue.
Great, let me know if you need further information or a test via HTTP/1.1.
I can't reproduce this. I was using a Windows 7.64.1 client. verbose
logging confirms both HTTP/2 and kerberos are being used.
Maybe re-test with 7.64.1 ? It looks like a curl bug at this point
although there are enough moving parts that it could be elsewhere.
Oh well, I've got a step further I do think that there is a bug in curl
and in Tomcat somewhere. I have updated the port to 7.64.1 and
recompiled. It does work now, in fact it exactly behaves like the
Windows version of curl 7.64.1. Two issues arise here:
1. Why did it fail with 7.64.0 and Tomcat while it worked with HTTPd?!
The dependencies of curl did not change.
2. If you change update=false both on Windows and FreeBSD curl hangs
forever and has to be killed. Make it update=true and it passes
flawlessly. (assuming that version 003 is already deployed).
Can you confirm? Do you need log outout?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
