Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Header "content-type" for multipart-request #347
While implementing the new approach, the following problem came up:
What to do, if a "content-type" is present in option "headers":
As we have all three approaches on other occassions in p:http-request, none seems more natural to me than the other.
But we need to say something - And I need to know, what to implement.
It's a good question. If I step back, it seems like we could make a high-level choice: either the implementation is supposed to interpret the values in the headers map and those values influence its behavior or the headers map is just copied to the request and exists for extra things that aren't part of the core HTTP spec.
I had the latter interpretation in mind, but we now have several places where that leads to potential conflicts. We should probably treat those conflicts in the same way. If the goal is to take the latter approach, I don't think option 3, comparing them and raising an error only if the values differ is the best approach. We should either ignore them or it should be an error if they exist at all in the headers map.
But part of my reason for thinking we would do the "just copy" approach is that it used to be much harder to specify headers than it was to specify options so it was at least a little bit about ease of use. Today, there's not much difference between:
In fact, I think you could make an argument that the headers case is simpler (it's less typing) and easier (it uses HTTP-technology not our invented parameters).
If we took the former approach, going back to my original statement, and argued that header values influence step behavior, we could remove the
Would that be better?
Ok, now I understand the reason why you made "multipart-content-type" etc. a parameter. To my understanding (before you made the last change)
Therefor for me it would seem more natural to remove
Does that make sense?