En le modifiant de quelle manière ?
De toute façon, sf::Http::Response est conçu comme étant une réponse HTTP (avec son en-tête et tout ce qu'il contient). Ca n'aurait pas vraiment de sens de coller du XML ou du JSON dedans.
Justement en modifiant l'utilisation de sf::HttpResponse : après tout m_body est un std::string, et je ne dis pas que ce serait propre ni que ça aurait du sens, mais que ça pourrait marcher (et à moi éviter de passer par un client HTPP très ennuyeux style cURL++ ou libwww).
Pour la manière, j'ai deux solutions : aucune n'est propre, mais ce sont loin d'être les seules solutions (la mieux serait surement que je me serve de SFML Network pour créer une classe "sf::XmlResponse" ou "sf::Xml" pour ne pas utiliser sf::Http, mais je ne suis pas sur de comment gérer la méthode POST). Soit je passe la méthode parse à une visibilité publique, et je retire son appel de la méthode sendRequest, remplaçant par une autre méthode ou par du code directement pour coller le contenu de "receivedStr" dans le httpResponse, sans parsing, et modifier les autres membre de httpResponse selon la situation... soit en créant une méthode "parseXML" et en faisant un test du style :
if (toSend.getField("Content-Type") == "application/xml")
parseXml(receivedStr);
else
parse(receivedStr);
Mis à part cela, je penses que les clients http servent le plus souvent à attaquer des webServices, et peu d'entre eux renvoi des informations au format html. Généralement, je penses qu'il s'agit de format adapté au rapatriement de données, issues de base de données par exemple. A ce jeu le xml et encore plus le json (ou encore le csv) sont d'excellents atouts.
De plus, dans d'autres langages, comme en C#, un framework comme .Net permet de deserialiser très facilement le contenu d'un XML pour l'intégrer dans un DTO (grace aux attributes notamment), et les client http permettent de renseigner le "Content-Type", ce qui a un véritable effet. C'est ce que je souhaiterais reproduire avec la SFML (la dernière partie sur le Content-Type").
Edit: pour exposer le contexte : j'ai un jeu de carte en ligne (client/serveur) assez abouti (jouable en LAN/WLAN pour le moment, et en ligne prochainement si j'arrive à mettre en place ce dont on parle), utilisant de fond en comble la SFML, j'ai un serveur WAMP installé et prêt à être utilisé, et pour que le joueur puisse se connecter via un compte, j'ai mis une table profil au point que j'attaque avec le client via une couche de webservices, afin d'autoriser des connexion, et rapatrier des données d'historique de partie, et de trouver des parties en cours, ce qui permettra au client de rejoindre une partie sans demander l'adresse ip à l'utilisateur. le webService que j'ai mis au point s'appuie sur CodeIgniter et utilise un protocole REST vraiment sympa d'utilisation, permettant même de choisir son format de retour de réposne : xml, json, ou csv... quand j'ai vu un client http avec la SFML, je me suis dit banco : "je vais pouvoir faire la même chose qu'en .Net au boulot avec les HttpClient du framework".C'est pour cela que je cherche un moyen de contourner ce petit souci de format de réponse.