Re: Expect: 100-continue not working with curl and HTTP/2

[Mark Thomas <ma...@apache.org>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org