ab2f616641
So far close() was called on underlying socket when timeout has expired. This is wrong in several ways. First of all POSIX specification of close() does not specify what should happen on blocking recv() call and different systems have different behaviors (e.g. Linux does not wake up recv() caller if there was no new incoming data, while other systems might wakeup recv() caller immediately). Another (and much more severe) problem is that HTTP client user does not know whether underlying socket was already closed or not after HTTP request has finished. As a result it was not clear whether close() should be called by HTTP client user. Use shutdown(..., SHUT_RD) in internal HTTP client implementation, so that recv() is woken up immediately with 0 as result (which means EOF). This will allow to gracefully handle timeouts and make it clear that it is application responsibility to always call close() after HTTP request (successful or not). Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com> |
||
|---|---|---|
| .. | ||
| capture | ||
| coap | ||
| config | ||
| conn_mgr | ||
| dns | ||
| http | ||
| lwm2m | ||
| mqtt | ||
| openthread | ||
| sntp | ||
| sockets | ||
| socks | ||
| tftp | ||
| tls_credentials | ||
| utils | ||
| websocket | ||
| CMakeLists.txt | ||
| Kconfig | ||