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.
I have now deployed the manager w/o authentication and there is no
change in behavior:
$ time curl --verbose --upload-file target/lda-docgen-webapp-0.1-backend-dev.war
'https://sitex-ldadw.ad001.siemens.net:8445/manager-1/text/deploy?path=/backend-dev&update=false&version=003'
* Uses proxy env variable NO_PROXY == 'localhost .siemens.net .siemens.com
.siemens.de'
* Trying 147.54.64.55...
* TCP_NODELAY set
* Connected to sitex-ldadw.ad001.siemens.net (147.54.64.55) port 8445 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /usr/local/etc/ssl/cert.pem
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=DE; O=Siemens; OU=LDA DW; CN=sitex-ldadw.ad001.siemens.net
* start date: Mar 19 13:10:13 2019 GMT
* expire date: Mar 19 13:10:13 2020 GMT
* subjectAltName: host "sitex-ldadw.ad001.siemens.net" matched cert's
"sitex-ldadw.ad001.siemens.net"
* issuer: C=DE; ST=Bayern; L=Muenchen; O=Siemens; serialNumber=ZZZZZZB7;
OU=Siemens Trust Center; CN=Siemens Issuing CA Intranet Server 2017
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x800d64000)
PUT /manager-1/text/deploy?path=/backend-dev&update=false&version=003 HTTP/2
Host: sitex-ldadw.ad001.siemens.net:8445
User-Agent: curl/7.64.1
Accept: */*
Content-Length: 6502139
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 200)!
< HTTP/2 200
< x-content-type-options: nosniff
< content-type: text/plain;charset=utf-8
< date: Sat, 30 Mar 2019 21:18:13 GMT
<
FAIL - Application already exists at path [/backend-dev##003]
^C
real 0m50,373s
user 0m21,498s
sys 0m28,861s
The result is identical on Windows. Curl completely hangs.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
