: > that scares me ... not only does it rely on the client code sending the : > correct content-type : : Not really... that would perhaps be the default, but the parser (or a : handler) can make intelligent decisions about that. : : If you put the parser in the URL, then there's *that* to be messed up : by the client.
but the HTTP Client libraries in vaious languages don't allways make it easy to set Content-type -- and even if they do that doesn't mean the person using that library knows how to use it properly -- put everyone understands how to put something in a URL. if nothing else, think of putting the "parsetype" in the URL as a checksum that the RequestParaser can use to validate it's assumptions -- if it's not there, then it can do all of the intellegent things you think it should do, but if it is there that dictates what it should do. (aren't you the one that convinced me a few years back that it was better to trust a URL then to trust HTTP Headers? ... because people understand URLs and put things in them, but they don't allways know what headers to send .. curl being the great example, it allways sends a Content-TYpe even if the user doesn't ask it to right?) : Multi-part posts will have the content-type set correctly, or it won't work. : The big use-case I see is browser file upload, and they will set it correctly. right, but my point is what if i want the multi-part POST body left alone so my RequestHandler can deal with it as a single stream -- if i set every header correctly, the "smart" parsing code will parse it -- which is why sometihng in the URL telling it *not* to parse it is important. : We should not preclude wacky handlers from doing things for : themselves, calling our stuff as utility methods. how? ... if there is one and only one RequestParser which makes the SolrRequest before the RequestHandler ever sees it, and parses the post body because the content-type is multipart/mixed how can a wacky handler ever get access to the raw post body? -Hoss
