jonsamwell
commented
8 years ago Hi @the-shultz
First off I'm glad you will be using the module!
If you have complete control over the way you build the response I would strongly advise you not to use the multipart request/response as in my opinion it is over complicated and can be solved with a much simpler JSON structure nowadays. I would favour doing it the way Facebook does (see https://developers.facebook.com/docs/graph-api/making-multiple-requests). I'd be happy to write an adapter for this library to handle that format.
If you decide to use the multi-part format I created the parser based off the HTTP1.1 spec and what a Microsoft Web API would return. I also worked from this https://cloud.google.com/storage/docs/json_api/v1/how-tos/batch.
I don't think I explicitly do any parsing of the Date header so this would just be pushed down the pipe to the requestor's handler to do with as they see fit (as I believe the headers are handled as strings).
Indeed to are correct in that the order of responses should match the order of requests. However, it would be fairly simple to add the concept of a correlation id etc.
Jon
Hi
We want to start and use your framework. Our server side is Java (tomcat), so we need to write ourselves the processing of the multipart request, and assemble the aggregated response to be delivered back to the client. I couldn't find on your documentation what should be the structure of the response. I have searched and found these two links describing how a multipart response should look alike, but then when comparing them to your code that processes the batch response, there are some inconsistencies: https://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html https://tools.ietf.org/id/draft-snell-http-batch-00.html#http-batch
After investigating the processResponse method, I came to the below structure: --[boundry] content-type: application/ (must be first among all headers, otherwise headers will be omitted)
[headers]..[headers]
[status (in the form of version code text)]
[empty line to separate between the metadata and the actual response data]
[the actual response data, which is carried until the next --boundry appears]
In addition, it seems that there is an assumption that the order of the responses is the same as the order of the requests (so the correlation between the response and request comes from there matching order).
Finally, I saw that the parsing of the date header, if such exists, omits the time and timezone fragments of it (you are treating it as a regular header and takes hardcoded the first part of it and only it).
My question is: Am I correct in my analysis ? did I miss something or got confused with anything ? are there any other limitation I need to take in mind in order to have a proper structure for the response ? Do you think you can add up a complete formal structure of the response to the documentation ?