On 1/20/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
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 -
I think we have to go with common usages. We neither rely on, nor discard content-type in all cases. - When it has a charset, believe it. - When it says form-encoded, only believe it if there aren't args on the URL (because many clients like curl default to "application/x-www-form-urlencoded" for a post.
- 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.
If it's optional in the args, I could be on board with that.
(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?)
Well, for the update server, we do ignore the form-data stuff, but we don't ignore the charset.
: 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.
That sounds like a pretty rare corner case.
: 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?
I wasn't thinking *that* whacky :-) There are always other options, such as using your own servlet though. I don't think we should try to solve every case (the whole 80/20 thing). -Yonik
