binary1248

I'm just saying the current implementation doesn't work properly already :wink:, so trying to preserve broken (for some users) behaviour doesn't make much sense to me. The fact is that...

So... is this issue still scheduled for fixing before SFML 3? If a more or less complete list can be provided of sites where error codes aren't checked, I can...

So... to create a sort of agenda for this issue... What needs to be done: - Find all the places where errors can happen, but are not currently handled -...

Pushed back to 2.5 since the Windows and OS X implementations are still not ready. For 2.4, #1022 can be merged instead of this in order to fix #1012.

So... what's the status on this issue? Does SFML need to be able to handle getting/setting multiple duplicate fields?

So... how would the interface need to be changed? Returning/Passing a container of values instead of single values?

I think renaming the existing methods would make more sense as well since we are really getting the value of a field and not the field itself (a field would...

Then... what about we add the variants with multiple values now with those names and rename the existing ones when SFML 3 comes around? :grin: Or... we could add all...

Actually... now that I had a closer look at the classes... Why don't `sf::Http::Request` and `sf::Http::Response` inherit from a base `sf::Http::Message` class? They set and get the same fields, and...

Almost all the methods in those 2 classes are just splitting the functionality of a generic `sf::Http::Message` class. The HTTP specification even refers to them both as "messages" the one...