On 30/03/2019 01:20, Michael Osipov wrote: > 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.
But curl did change so my working assumption is a curl bug. > 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). Tomcat was not doing the HTTP/2 equivalent of swallowing unwanted input. I have a patch that I'll commit shortly that cancels the stream in this instance. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
