Well, from what you quote from 91.1., it looks like, at worst, I would be doing something I "SHOULD NOT" which means it's not a violation of the spec. RFC 2119 says things with this label may be acceptable or usefule, but implications should be understood and the case carefully weighed.
The bit from 9.3 you quote, (and the rest, for that matter), don't seem to specifically rule out GET having a body, at least in my mind. As I mentioned previously, I'm thinking in terms of RESTful interactions where the URI could specify a resource that is a collection. After this discussion I'm not dissuaded from doing things this way, but I'm willing to accept HttpGet not being modified. @D olegk wrote: > > 9.1.1 > "... > In particular, the convention has been established that the GET and > HEAD methods SHOULD NOT have the significance of taking an action > other than retrieval. > ..." > > 9.3 > "... > The GET method means retrieve whatever information (in the form of an > entity) is identified by the Request-URI. > ..." > > Hope this helps > > Oleg > >> @D >> >> David, >> >> What you are trying to do / propose is a severe violation of the HTTP >> spec. See section 9.1 >> >> Oleg >> >> >> > @D >> > >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Message-body-in-GET-method--tp17994858p18018800.html Sent from the HttpClient-User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
