: I have imagined the single default parser handles *all* the cases you : just mentioned.
Ahhhhhhhhhhhh ... a lot of confusing things make more sense now. .. but some things are more confusing: If there is only one parser, and it decides what to do based entirely on param names and HTTP headers, then what's the point of having the parser name be part of the path in your URL design? : POST: depending on headers/content type etc you parse the body as a : single stream, multi-part files or read the params. : : It will take some careful design, but I think all the standard cases : can be handled by a single parser. that scares me ... not only does it rely on the client code sending the correct content-type (i don't trust HTTP Client code -- but for the sake of argument let's assume all clients are perfect) what happens when a person wants to send a mim multi-part message *AS* the raw post body -- so the RequestHandler gets it as a single ContentStream (ie: single input stream, mime type of multipart/mixed) ? This may sound like a completely ridiculous idea, but consider the situation where someone is indexing email ... they've written a RequestHandler that knows how to parser multipart mime emails and convert them to documents, they want to POST them directly to Solr and let their RequestHandler deal with them as a single entity. ..i think life would be a lot simpler if we kept the RequestParser name as part of hte URL, completely determined by the client (since the client knows what it's trying to send) ... even if there are only 2 or 3 types of RequestParsing being done. -Hoss
