0
I am simulating a peer-to-peer network which uses HTTP as an application protocol and I have some uncertainty regarding how a client knows what an HTTP response will consist of.
Let's assume that a client sends an MPD (information about a video) request to an HTTP server: GET /video.mpd HTTP/1.1
The server replies with the MPD content and also attaches additional parameters which are NOT part of the MPD to the message body: [MPD content...]?parent1ID=5&parent2ID=7
I'm assuming that the client knows how to interpret the MPD content since it requested it in the first place. The client will however receive additional details about its parents which are not part of the MPD.
In reality, is there a way for the client to know that it is expecting parent1ID and parent2ID parameters as well and how to interpret them? If so, how does the client determine that? If not, what can be done so that a client is able to receive additional parameters?
I answered the plain HTTP part of your question as indicated by your title, but upon re-reading the body of your question I see you really might also be asking something specific to MPEG-DASH video streaming. You may want to ask your MPEG-DASH question as a separate question post, focused on MPEG-DASH. – Spiff – 2019-09-28T18:36:04.533
It was actually concerned towards the HTTP part which you managed to answer. The multipart media-type for the Content-type header is what I was looking for. Thanks mate! – Mulishia – 2019-09-28T18:45:44.453
The server will never "attach additional parameters to the content", in particular not using the URL format. If the server wants to supply additional information, it does so by adding headers to the response. And of course it can manipulate the body in any way it pleases, but normally it will take care not to do this in a way that isn't conforming to whatever format the body is in (that would be a bug in the server). – dirkt – 2019-09-28T20:15:59.650