[Libwebsockets] Settings Frame size above max / Flow control exceeded max

Andreas Lobbes Andreas.Lobbes at thinprint.com
Wed Jul 10 16:12:46 CEST 2019


Hello Andy,

yes, the additional headers were bad,
I fixed this an now I get a HTTP response as expected.

Thanks a lot,
Andreas

________________________________________
From: Andy Green [andy at warmcat.com]
Sent: Wednesday, July 10, 2019 10:36 AM
To: Andreas Lobbes; libwebsockets at ml.libwebsockets.org
Subject: Re: [Libwebsockets] Settings Frame size above max / Flow control exceeded max

On 7/10/19 7:18 AM, Andreas Lobbes wrote:

The two sides are heavily pipelined I think... there's no sequential
relationship between what's happening in the logs since each side fires
off a salvo of what it wants.

The only thing that looks odd to me is the headers

2019-07-10 08:08:55 DBG 0000: 00 01 0E 01 04 00 00 00 03 00 07 3A 6D 65
74 68    ...........:meth
2019-07-10 08:08:55 DBG 0010: 6F 64 04 50 4F 53 54 00 07 3A 73 63 68 65
6D 65    od.POST..:scheme
2019-07-10 08:08:55 DBG 0020: 04 68 74 74 70 00 05 3A 70 61 74 68 14 2F
6F 61    .http..:path./oa
2019-07-10 08:08:55 DBG 0030: 75 74 68 2F 61 63 63 65 73 73 5F 74 6F 6B
65 6E    uth/access_token
2019-07-10 08:08:55 DBG 0040: 2F 00 0A 3A 61 75 74 68 6F 72 69 74 79 1B
61 63    /..:authority.ac
2019-07-10 08:08:55 DBG 0050: 63 6F 75 6E 74 2E 64 65 76 2E 61 7A 64 65
76 2E    count.dev.azdev.
2019-07-10 08:08:55 DBG 0060: 65 7A 65 65 70 2E 63 6F 6D 61 75 74 68 6F
72 69    ezeep.comauthori
2019-07-10 08:08:55 DBG 0070: 7A 61 74 69 6F 6E 3A 20 42 61 73 69 63 20
XX XX    zation: Basic XX
2019-07-10 08:08:55 DBG 0080: XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX    XXXXXXXXXXXXXXXX
2019-07-10 08:08:55 DBG 0090: XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX    XXXXXXXXXXXXXXXX
2019-07-10 08:08:55 DBG 00A0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX    XXXXXXXXXXXXXXXX
2019-07-10 08:08:55 DBG 00B0: XX XX XX XX XX XX 0D 0A 61 63 63 65 70 74
3A 20    XXXXXX..accept:
2019-07-10 08:08:55 DBG 00C0: 61 70 70 6C 69 63 61 74 69 6F 6E 2F 6A 73
6F 6E    application/json
2019-07-10 08:08:55 DBG 00D0: 0D 0A 63 6F 6E 74 65 6E 74 2D 74 79 70 65
3A 20    ..content-type:
2019-07-10 08:08:55 DBG 00E0: 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 2D
77 77    application/x-ww
2019-07-10 08:08:55 DBG 00F0: 77 2D 66 6F 72 6D 2D 75 72 6C 65 6E 63 6F
64 65    w-form-urlencode
2019-07-10 08:08:55 DBG 0100: 64 0D 0A 63 6F 6E 74 65 6E 74 2D 6C 65 6E
67 74    d..content-lengt
2019-07-10 08:08:55 DBG 0110: 68 3A 20 38 36 0D 0A
         h: 86..

h2 headers can be made of uncompressed literals like this but at the
end, there shouldn't be any 0x0d 0x0a.  What does your code look like
that's producing that?

Notice that there is this:

/**
  * lws_finalize_http_header() - terminate header block
  *
  * \param wsi: the connection to check
  * \param p: pointer to current position in buffer pointer
  * \param end: pointer to end of buffer
  *
  * Indicates no more headers will be added
  */
LWS_VISIBLE LWS_EXTERN int LWS_WARN_UNUSED_RESULT
lws_finalize_http_header(struct lws *wsi, unsigned char **p,
                         unsigned char *end);

it is aware if the wsi is h2 and acts correctly... it's not right to
just stick another CRLF on the end to terminate the headers as on h1.
The minimal examples are using this or its friend
lws_finalize_write_http_header() which combines it with the correct kind
of lws_write().

-Andy





More information about the Libwebsockets mailing list