I think the answer will come back from the regulars on the httpclient dev list that the long term intent is to split the "request", and "response" parts of the HttpMethod interface into distinct pieces. As part of those new interfaces, your suggestions certainly make sense. Unfortunately, adding to the existing HttpMethod interface *could* break existing code that doesn't inherit from HttpMethodBase (although as a practical manner, I'm not sure that anyone out there could realistically implement HttpMethod without extending HttpMethodBase, part of its architectural flaw).
Defining the constants in some place makes sense, and perhaps those are good utility functions? I think there might be some other subtleties going on here, but I've not really considered this part of the code before.
I think various HttpClient commiters are on vacation until Jan., so I wouldn't expect a more complete response before then.
-Eric.
Gary Gregory wrote:
Hello HttpClient,
For our code which uses HttpClient, I find myself defining constants and methods in our code for things like "Content-Type" header handling. I am surprised not to find such a constant in HttpClient in a "public" place. (It is defined in multipart.Part as protected).
I also see a lot of getRequestHeader("Content-Type") and setRequestHeader("Content-Type", ...).
This is seem like a good opportunity for a refactoring, in this case to getContentType() and setContentType(String).
Is there any reasons these methods do not exist?
I am a committer on [lang] and [codec] (also dabbling in [vsf]) and can help out directly or via patches if the group is interested in moving in this direction.
Thanks for reading, Gary
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
