: I'll comment on points i have answers or questions. The rest will go : on the TODO list.
Um... just for the record, some of these comments -- i'm not sure what they are in reponse too :) : To trigger raw request reading you *must* have a parameter on the URL. : This was my design in response to Yonik's observation that curl puts : "application/x-www-form-urlencoded" in the header even if it is not : form-urlencoded encoded. : : As written, it does not rely on clients putting accurate headers : (except for multipart) - it relies on a URL convention. Yonik's point was that we need to do that when supporting *legacy* requests ... since we are designing a new mechanism which will live at a new URL in the example (and which clients would have to explicitly map to the old URL in their configs) we have the freedom to be more strict in our parsing. we should require that people send us a Content-Type if they want to post data to us -- and we should use that content-Type to determine how to parse the content. (this is one of the reasons i'm suggesting we keep the existing Servlets arround -- that way we don't have to be worried about them so much as we tweak the new classes) : I only put it in there to make you happy! I'll take it out and we can : deal with it later if necessary. : : I didn't think i could get that past you! I'll take it out and save : the pleeding for another time. these are the comments where i'm not sure what they are refering to. : for a local file, you can use stream.url=file:///C:/pathtofile.txt, : for remote ones, you use stream.url=http://... oh yeah ... why didn't i think of that? : We should have a good notice in the config warning people to have some : security running before enabling streaming. yeah ... you had me convinced of that before, but i'm leaning more towards yonik's point now: Solr has a lot of inherient trust to anyone that can hit it directly. if/when we allow the list of RequestParsers to be configurable in solrconfig.xml, then the STREAM_URL support could be another RequestParser that they either refer to directly, or register as a "hook" on other RequestParsers. In the meantime though: having that option might misslead people to a false sense of security. : I had implemented it the normal way, BUT it broke many tests (since : they never call init). The better solution is to make sure the tests : call init a standard way, but that got me into editing many files I : don't quite understand, so i opted for lazy init. i don't understand ... why weren't your tests calling init? ... if you were doing everything via the TestHarness it inits the SolrCore which inits all the requesthandlers -- if you were constructing the RequestHandler yourlse you could just call the init(NamedList) method directly. BTW: something i keep forgetting to mention, is that it would be helpful if you could setup your IDE to use 2 spaces per tab-stop, and never use tab characters ... it'll make the patches easier to apply. (not every Solr source file is like that right now ... but it's the goal) -Hoss
