readtimeout of zero will not send the request

The following code will not send a request:

``` python
endpoint = 'some.server.com'
data = {'foo':123}
requests.post(self._endpoint , json=data,
                          verify=False, timeout=(5, 0.00))
```

I would expect the library to send the request but not wait for the server to respond. This would correspond to a fire and forget type of request particularly useful for logging of non critical information


What does "will not send the request" mean? On my system, the request _is_ sent, but a `ReadTimeoutError` is raised, which feels like exactly the expected behaviour. What are you seeing that makes you believe that's not happening for you?

Please note, however, that setting a timeout of exactly zero is [a _bad idea_](https://github.com/kennethreitz/requests/issues/2699#issuecomment-126494944): see #2699 for more. We plan to forbid doing that entirely in future: instead, you should choose a small floating point value.


So "will not send the request" means that the request isn't sent to my server when the timeout is set to zero. I also get the ReadTimeoutError but no sending occurs.  My request is sent if i raise the read timeout from 0 to 0.01. Based on #2699 that it would be a bad idea for the library but its not bad from a usage perspective. In other words setting a read timeout of zero seems to me to be a valid use case even if the underlying socket implementation has a bug in it. 

However if you ended up forbidding it and provided a workaround, that would be better than it _sometimes_ working. I just hope that its not a race condition of some kind and that if you reduced the timeout to some arbitrarily small number that you would start to see what i was experiencing.


@trcarden Our intention is that we will forbid it: it's simply not a sensible thing to pass to this library. Generally speaking, the better logic for a 'fire-and-forget' request is to set `stream=True` and simply close the request afterwards. This will ensure that the server really did receive the request, but won't block on reading any of the response body.


> but won't block on reading any of the response body.

It will block on reading the headers though fwiw


Ok, I am trying to be practical here. I don't want to wait on the response coming back from the server but i do want to obligate the system to send the request. I could use UDP sockets but that requires a new server and a bunch more overhead. I completely understand TCP/IP and HTTP aren't really built for this but i think i can get 90%+ of what i need just setting a small value on the read-timeout. I did read in a couple places that setting a timeout of zero doesn't "obligate" the system to send the message (might only make it to buffers without getting transmitted) depending on the local implementation so i see why my problem might have been occurring. 

@sigmavirus24 thank you for the note on the headers. Emulating a "best effort" protocol on top of TCP/IP and HTTP with a upper bound on total wait time (limitations acknowledged) seems to work better with low read-timeout settings than enabling streaming responses. Eventually I think we will enable a UDP server.