Re: [HttpClient] Refactor get/setRequestHeader(Content-Type,..)
Hi Gary, I agree, constants like Content-Type along with quite a few others are duplicated throughout the HttpClient code. Mostly this is because no-one has spent the time to clean them up. As Eric mentioned convenience methods have not been added to HttpMethod for compatibility reasons. Also, since there are so many commonly used headers we have not wanted to muddy up the HttpMethod interface with more methods. My preference would be to add header utility methods to another static class, HeaderUtil or something of the like. This class could have a bunch of constants for the various commonly used header names, as well as methods for more complicated header elements like Content-Type (e.g. HeaderUtil.createContentTypeHeader(text/html, UTF-8)). As always patches are quite welcome. Mike On Dec 23, 2003, at 3:43 PM, 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]
Re: [HttpClient] Refactor get/setRequestHeader(Content-Type,..)
Ugh - cross-posting. Seems like this question was meant for httpclient-dev, so I've included that 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]
