libwebsockets/doc/html/group__client.js

28 lines
2.4 KiB
JavaScript
Raw Permalink Normal View History

var group__client =
[
[ "lws_client_connect_info", "structlws__client__connect__info.html", [
[ "_unused", "structlws__client__connect__info.html#ad47f50d1633dc5df74548606c9a66d73", null ],
[ "address", "structlws__client__connect__info.html#aa364094f94ef1bcaaabbd9161971d502", null ],
[ "client_exts", "structlws__client__connect__info.html#a7732b996e977393c3e1076be2a8ded6c", null ],
[ "context", "structlws__client__connect__info.html#afe999d133cc240a0bfd02aade0514cfd", null ],
[ "host", "structlws__client__connect__info.html#a9b36d47c3422329df32c21040a35ebc7", null ],
[ "ietf_version_or_minus_one", "structlws__client__connect__info.html#a69abb5aeed755750b9755e5c91db6895", null ],
[ "method", "structlws__client__connect__info.html#aa9e8e3da4e783a0651b0dea62c2dd1db", null ],
[ "origin", "structlws__client__connect__info.html#a8595f83e64147cb687b6418cf500dd4c", null ],
[ "parent_wsi", "structlws__client__connect__info.html#a6843a60e1050b10db9d98d7eeb45f587", null ],
[ "path", "structlws__client__connect__info.html#a76a8388733f114fb8fd3643874781185", null ],
[ "port", "structlws__client__connect__info.html#a1af124d81c3c22a46d39387c5bc3d6b9", null ],
[ "protocol", "structlws__client__connect__info.html#aba35adfb74845a5fd0c3dc141cbdddd2", null ],
CLIENT_CONNECTION_ERROR add strings This clears up a couple of issues with client connect. - if CLIENT_CONNECTION_ERROR is coming, which of the many ways the rejection may have happened is documented in the in argument. It's still possible if it just got hung up on in will be NULL, but now it has MANY more canned strings describing the issue available at the callback "getaddrinfo (ipv6) failed" "unknown address family" "getaddrinfo (ipv4) failed" "set socket opts failed" "insert wsi failed" "lws_ssl_client_connect1 failed" "lws_ssl_client_connect2 failed" "Peer hung up" "read failed" "HS: URI missing" "HS: Redirect code but no Location" "HS: URI did not parse" "HS: Redirect failed" "HS: Server did not return 200" "HS: OOM" "HS: disallowed by client filter" "HS: disallowed at ESTABLISHED" "HS: ACCEPT missing" "HS: ws upgrade response not 101" "HS: UPGRADE missing" "HS: Upgrade to something other than websocket" "HS: CONNECTION missing" "HS: UPGRADE malformed" "HS: PROTOCOL malformed" "HS: Cannot match protocol" "HS: EXT: list too big" "HS: EXT: failed setting defaults" "HS: EXT: failed parsing defaults" "HS: EXT: failed parsing options" "HS: EXT: Rejects server options" "HS: EXT: unknown ext" "HS: Accept hash wrong" "HS: Rejected by filter cb" "HS: OOM" "HS: SO_SNDBUF failed" "HS: Rejected at CLIENT_ESTABLISHED" - until now the user code did not get the new wsi that was created in the client connection action until it returned. However the client connection action may provoke callbacks like CLIENT_CONNECTION_ERROR before then, if multiple client connections are initiated it makes it unknown to user code which one the callback applies to. The wsi is provided in the callback but it has not yet returned from the client connect api to give that wsi to the user code. To solve that there is a new member added to client connect info struct, pwsi, which lets you pass a pointer to a struct wsi * in the user code that will get filled in with the new wsi. That happens before any callbacks could be provoked, and it is updated to NULL if the connect action fails before returning from the client connect api.
2016-07-01 08:54:39 +08:00
[ "pwsi", "structlws__client__connect__info.html#a065063b5117ecd0a59567c97f04bda2e", null ],
[ "ssl_connection", "structlws__client__connect__info.html#a9862297827639238a7a0b4054c3ddf3d", null ],
[ "uri_replace_from", "structlws__client__connect__info.html#a03c305fdca809667b6a9a83b3edfd83a", null ],
[ "uri_replace_to", "structlws__client__connect__info.html#a9959ba103d3d2484e559a9f7879eebe3", null ],
[ "userdata", "structlws__client__connect__info.html#a9831b9f9ab54a1aec4bb15324f1c3836", null ],
[ "vhost", "structlws__client__connect__info.html#a3893181d728f326f9f5b47c1459cb8be", null ]
] ],
[ "lws_client_connect_ssl_connection_flags", "group__client.html#ga96f3dbad54b2853969cfa933d66871ce", null ],
[ "lws_client_connect", "group__client.html#ga4af0a20108a95e8b6d94dd4d80055ff3", null ],
[ "lws_client_connect_extended", "group__client.html#gac6a8558b4410961a880241c2ac1271e2", null ],
CLIENT_CONNECTION_ERROR add strings This clears up a couple of issues with client connect. - if CLIENT_CONNECTION_ERROR is coming, which of the many ways the rejection may have happened is documented in the in argument. It's still possible if it just got hung up on in will be NULL, but now it has MANY more canned strings describing the issue available at the callback "getaddrinfo (ipv6) failed" "unknown address family" "getaddrinfo (ipv4) failed" "set socket opts failed" "insert wsi failed" "lws_ssl_client_connect1 failed" "lws_ssl_client_connect2 failed" "Peer hung up" "read failed" "HS: URI missing" "HS: Redirect code but no Location" "HS: URI did not parse" "HS: Redirect failed" "HS: Server did not return 200" "HS: OOM" "HS: disallowed by client filter" "HS: disallowed at ESTABLISHED" "HS: ACCEPT missing" "HS: ws upgrade response not 101" "HS: UPGRADE missing" "HS: Upgrade to something other than websocket" "HS: CONNECTION missing" "HS: UPGRADE malformed" "HS: PROTOCOL malformed" "HS: Cannot match protocol" "HS: EXT: list too big" "HS: EXT: failed setting defaults" "HS: EXT: failed parsing defaults" "HS: EXT: failed parsing options" "HS: EXT: Rejects server options" "HS: EXT: unknown ext" "HS: Accept hash wrong" "HS: Rejected by filter cb" "HS: OOM" "HS: SO_SNDBUF failed" "HS: Rejected at CLIENT_ESTABLISHED" - until now the user code did not get the new wsi that was created in the client connection action until it returned. However the client connection action may provoke callbacks like CLIENT_CONNECTION_ERROR before then, if multiple client connections are initiated it makes it unknown to user code which one the callback applies to. The wsi is provided in the callback but it has not yet returned from the client connect api to give that wsi to the user code. To solve that there is a new member added to client connect info struct, pwsi, which lets you pass a pointer to a struct wsi * in the user code that will get filled in with the new wsi. That happens before any callbacks could be provoked, and it is updated to NULL if the connect action fails before returning from the client connect api.
2016-07-01 08:54:39 +08:00
[ "lws_client_connect_via_info", "group__client.html#ga0c966136905f467816307cfba6deb5fd", null ],
[ "lws_init_vhost_client_ssl", "group__client.html#ga4f44b8230e6732816ca5cd8d1aaaf340", null ]
];