Project

General

Profile

Actions

Bug #7273

closed

Http client waits till timeout when server returns status code 204

Added by max p over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
10/07/2019
Due date:
% Done:

0%

Estimated time:

Description

This was observed when implementing a request to delete a calendar item from google calendar.

In this case, Google server returns status code 204 without any payload and the HTTP client waits a configured timeout till emitting 'done' event with status code 204.

The expected behavior would be to emit 'done' event as soon as response with code 204 is received.

Actions #1

Updated by Roel Standaert over 4 years ago

  • Status changed from New to Feedback
  • Priority changed from Urgent to Normal

So I guess Google is not sending a Content-Length header when they send a 204, but they're also not closing the connection either? Do you have examples of such requests, some way to reproduce this?

Actions #2

Updated by Roel Standaert over 4 years ago

As a workaround, you can also abort() after you got the headersReceived() signal.

Actions #3

Updated by max p over 4 years ago

Hi,

here is the verbose output from curl:

curl -v https://www.googleapis.com/calendar/v3/calendars/2l9p2n6hc88dac5ukeakpu6pi8@group.calendar.google.com/events/ -X DELETE -H 'Authoriz[7/1461]

earer '

  • Trying 172.217.168.74...
  • TCP_NODELAY set
  • Connected to www.googleapis.com (172.217.168.74) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
  • TLSv1.3 (IN), TLS handshake, Unknown (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, Client hello (1):
  • TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
  • 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=US; ST=California; L=Mountain View; O=Google LLC; CN=*.googleapis.com
  • start date: Oct 3 17:15:29 2019 GMT
  • expire date: Dec 26 17:15:29 2019 GMT
  • subjectAltName: host "www.googleapis.com" matched cert's "*.googleapis.com"
  • issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
  • 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
  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):
  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):
  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):
  • Using Stream ID: 1 (easy handle 0x5637252fc3f0)
  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):
    > DELETE /calendar/v3/calendars/2l9p2n6hc88dac5ukeakpu6pi8@group.calendar.google.com/events/ HTTP/2
    > Host: www.googleapis.com
    > User-Agent: curl/7.58.0
    > Accept: /
    > Authorization: Bearer
    >
  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • TLSv1.3 (IN), TLS Unknown, Unknown (23):
  • Connection state changed (MAX_CONCURRENT_STREAMS updated)!
  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):
  • TLSv1.3 (IN), TLS Unknown, Unknown (23):
  • TLSv1.3 (IN), TLS Unknown, Unknown (23):
    < HTTP/2 204
    < cache-control: no-cache, no-store, max-age=0, must-revalidate
    < pragma: no-cache
    < expires: Mon, 01 Jan 1990 00:00:00 GMT
    < date: Mon, 21 Oct 2019 17:24:16 GMT
    < vary: Origin
    < vary: X-Origin
    < server: GSE
    < alt-svc: quic=":443"; ma=2592000; v="46,43",h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000
  • TLSv1.3 (IN), TLS Unknown, Unknown (23):
  • TLSv1.3 (IN), TLS Unknown, Unknown (23):
  • TLSv1.3 (OUT), TLS Unknown, Unknown (23):

Less clumsy output from curl:

curl -i https://www.googleapis.com/calendar/v3/calendars/2l9p2n6hc88dac5ukeakpu6pi8@group.calendar.google.com/events/ -X DELETE -H 'Authorization: Bearer '

HTTP/2 204

cache-control: no-cache, no-store, max-age=0, must-revalidate

pragma: no-cache

expires: Mon, 01 Jan 1990 00:00:00 GMT

date: Mon, 21 Oct 2019 17:30:22 GMT

vary: Origin

vary: X-Origin

server: GSE

alt-svc: quic=":443"; ma=2592000; v="46,43",h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000

Actions #4

Updated by Roel Standaert over 4 years ago

Hm, what Wt's HTTP client sees may not be entirely the same, since it doesn't use HTTP/2, but it does seem that this response doesn't declare any content length.

Actions #5

Updated by max p over 4 years ago

So what would be helpful? I can't simply extract this code from my app because many other components are involved.

Isn't it a good solution to emit done() when headers are received? (a workaround you've suggested to abort when headers are received)

Actions #6

Updated by Roel Standaert over 4 years ago

I think you can limit curl to use HTTP/1.1, but I'll try to check it out myself. What you're doing is deleting an event from a google calendar?

Actions #7

Updated by max p over 4 years ago

Yes. I'm just deleting an event from a google calendar and server responds with 204 status code.

Actions #8

Updated by Roel Standaert over 4 years ago

  • Status changed from Feedback to Resolved

I managed to test this with https://httpstat.us/204. I pushed a fix.

Actions #9

Updated by max p over 4 years ago

thanks :)

Actions #10

Updated by Roel Standaert over 4 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF