Please see the travis log

Ok, I see, there is a lot of connections with this error handling part. Client code and unit tests expect a certain behavior. So I will think how I can eject 413 error message gentle way.

@alateas That's not the point. The point is that you moved the part where message is parsed further down, and now other parts of the code that need that variable don't work

Oh I'm sorry, you already fixed that 😄

Reason of moving block of http error handling( https://github.com/python-telegram-bot/python-telegram-bot/blob/master/telegram/utils/request.py#L191-L200 ) up is this block will never be executed. Because if we, for example, get a 502 http error, any way data will parsed in 187 line and json parsing will raise ValueError in 134 line, because it will not be real json.

Any way my last fix was wrong too :)

Can't you insert the check between the 200-209 check and the message parsing in the original file? It doesn't need the message.

I can, but this check the similar with other http error checks at lines 191-200, will be strange to separate 413 http error check.

@alateas I have a fix for your fix :-)
however, it seems that you haven't allowed edits to your branch by maintainers. Can you please allow it and I'll push? See:
https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/

@tsnoam Good news! Actually I have allowed maintainers edits, I rechecked it right now.

I failed to push my commit. I wonder if I do something wrong.
Anyhow, I just edited the code using the github web interface. I hope I haven't made any typo.
Now we'll wait for travis to see if it works.

I I see this correctly. The way it is in the latest commit it will never raise an error if there is an error but not in one of the error codes. Shouldn't we add an

else:
  raise NetworkError(message)

at the bottom?

Nevermind, it just fell off the screen. It looks good to me.

@alateas thanks for your contribution.