DO NOT REPLY [Bug 20986] - Contributed utility for determing content type from file type extension
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20986. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20986 Contributed utility for determing content type from file type extension --- Additional Comments From [EMAIL PROTECTED] 2003-06-21 13:44 --- Created an attachment (id=6927) source code - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PATCH org.apache.commons.httpclient.methods.multipart.FilePart
Hey Adrian, Its in http://issues.apache.org/bugzilla/show_bug.cgi?id=20986 I put it source in the description and attached it. Eric -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Saturday, June 21, 2003 12:01 AM To: Commons HttpClient Project Subject: Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart Hi Eric, Thanks for your effort, unfortunately attachments don't seem to come through on the list. Could you create a new bug in bugzilla for this and attach the file to that? Thanks, Adrian Sutton On Saturday, June 21, 2003, at 12:57 PM, Eric M Devlin wrote: Hey Mike, Adrian Oleg Got it. Thanks for the kick in the right direction. I wasn't seeing addPart. Please find attached the contrib file. Hope it helps someone else. I tried to make it as apacheish as possible if it needs any changes just let me know. Thanks to everyone working on httpclient. It's been a really nice find. I'm using to at work, but I've gotten more out of it at home. Eric -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 11:01 PM To: Commons HttpClient Project Subject: Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart Eric, You want to create the FilePart manually and then add it to the MultipartPostMethod. Something like: MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080/something; ); FilePart part = new FilePart(name, file, contentType, charset); mpm.addPart(part); Mike On Thursday, June 19, 2003, at 10:23 PM, Eric M Devlin wrote: Hey Adrian, Ok, but what about what something below? MultipartPostMethod mpm = new MultipartPostMethod( http://localhost:8080; + /something ); mpm.addParameter( A, new File( /usr/dev/images/add.gif ) ); How do I set the content type for the file? It seems either the addParameter needs to return FilePart which would have to have setters provided or an overloaded version of addParameter which accepted the content type and charset. //MultipartPostMethod public void addParameter(String parameterName, File parameterFile, String contentType, String charset ) -- or -- //MultipartPostMethod public FilePart addParameter(String parameterName, File parameterFile ) //FilePart public void setContentType( String contentType ) public void setCharset( String charset ) I've got the code pulled into class but without a place to apply it's going to be pretty useless. ;- I think this is why I was putting the contentType determination in the FilePart class it self. Just let me know. Eric -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:10 PM To: Commons HttpClient Project Subject: Re: PATCH org.apache.commons.httpclient.methods.multipart.FilePart Hi Eric, This isn't really something that should be included directly into HttpClient as HttpClient isn't intended to care about the actual content it sends and receives but just takes care of the actual HTTP protocol side of things. Adding auto-mime type detection would mean we'd also have to provide a way to configure the default mime-types etc, in other words it opens a whole can of worms. However, this would be an excellent submission to the HttpClient contrib package, particularly if we refactor it so that instead of being a patch it's a complete class that extends FilePart to add the functionality, then it could easily be used without any changes to HttpClient. Would you be happy with that course of action? If so, would you like to adapt the patch into a standalone class yourself or would you like me to take a crack at it? I don't mind either way. Thanks a lot for the contribution, it will definitely be useful to a number of people. Regards, Adrian Sutton. On Thursday, June 19, 2003, at 12:46 PM, Eric M Devlin wrote: Hey, This is a patch which will determine the content type if null based on file extension. I used the file extension mapping from $TOMCAT_HOME/conf/web.xml. As a side note, I'm having trouble sending gif files. Any thoughts or a kick in the right direction would be helpful. Thanks and Hope It Helps Eric contentTypeByExtension.txt- - - -- 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] - 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]
form urlencoding, was Re: URI query escapes
Laura, After looking into this some more I agree that query parameters should be form urlencoded. The query param=value convention is an HTML specification and has nothing to do with URIs. Fortunately it turns out that form urlencoded values conform to the specification for URI queries. While investigating this question I discovered something else about form urlencoding that is strange. It seems that the characters *, -, _ and . are not encoded by browsers (IE, Mozilla and Safari). I am not sure why this is from reading the spec but it seems fairly consistent. I am also wondering why we are not using the java.net.URLEncoder for this (is also does not encode *-_.). I propose that we: - form urlencode values passed to HttpMethodBase.setQueryString(NameValuePair[]) - use java.net.URLEncoder for form urlencoding Any thoughts, objections? Mike On Friday, June 20, 2003, at 06:05 PM, Laura Werner wrote: Michael Becke wrote: Yes, but this is for application/x-www-form-urlencoded values. Currently we only assume this content type for post params (this was recently fixed). I think we have to assume it for get params too. In the HTTP 4.01 spec, 17.13.3.4 http://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.4: If the method is get and the action is an HTTP URI, the user agent takes the value of action, appends a `?' to it, then appends the form data set, encoded using the application/x-www-form-urlencoded content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes. So urlencoded seems like the right default for get query parameters. -- Laura BTW, how do you all feel about newsgroup posts in HTML format? I left this one in HTML because of all the links, but I'll stop if any of you have news readers that can't deal with it. - 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]
Re: form urlencoding, was Re: URI query escapes
Michael Becke wrote:
I propose that we:
- form urlencode values passed to
HttpMethodBase.setQueryString(NameValuePair[])
- use java.net.URLEncoder for form urlencoding
I agree, as long as URLEncoder seems to work.
Do you think we need to modify URI so that it uses URLEncoder to encode
the query part of URIs? In cases where a client has a URL string that
may or may not contain query parameters, it would lead to a slightly
more natural API usage:
HttpMethod meth = new GetMethod(new URI(urlString));
as opposed to
String query = null;
int index = urlString.indexOf('?');
if (index != -1) {
query = urlString.substring(index+1);
urlString = urlString.substring(0, index);
}
HttpMethod meth = new GetMethod(new URI(urlString));
meth.setQueryString(java.net.URLEncoder.encode(query));
or something like that, with error checking of course.
I'm not sure how much I care, though. If my fetching code had been
constructed using the HttpClient code from scratch, I wouldn't even have
the query parameters in the string in the first place; I'd just add them
with setQueryString.
I'll see if I can work up a preliminary patch for this stuff later
tonight or tomorrow morning.
Adrian Sutton wrote:
I know in the product we develop, we switched away from using
java.net.URLEncoder because it didn't work properly
FWIW, we're using it and haven't seen any problems. But we've been on
1.2 or higher since I started at BeVocal. (We're moving to 1.4 now
because the server VM performance is *much* better.)
--Laura
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: form urlencoding, was Re: URI query escapes
On Saturday, June 21, 2003, at 11:47 PM, Laura Werner wrote:
I agree, as long as URLEncoder seems to work.
Do you think we need to modify URI so that it uses URLEncoder to
encode the query part of URIs? In cases where a client has a URL
string that may or may not contain query parameters, it would lead to
a slightly more natural API usage:
HttpMethod meth = new GetMethod(new URI(urlString));
as opposed to
String query = null;
int index = urlString.indexOf('?');
if (index != -1) {
query = urlString.substring(index+1);
urlString = urlString.substring(0, index);
}
HttpMethod meth = new GetMethod(new URI(urlString));
meth.setQueryString(java.net.URLEncoder.encode(query));
or something like that, with error checking of course.
I don't think URI should be doing any form urlencoding. The URI spec
does not use the concept of query params. It just treats the entire
query as a single entity.
Also, when creating a URI containing query params, the params must be
encoded before the URI is generated otherwise it will not be parsable.
For example, when creating a URI with the following query params:
NameValue
param1 value1
param2 value=2
If not pre-encoded, the URI would look something like
http://host/path?param1=value1param2=value=2;.
Once joined together it is too late to encode. This is why the
HttpMethod(String) constructor assumes that all URIs are already
encoded, as it is not possible to correctly encoded them after the fact.
Please let me know if you will be writing some code for this as I will
take care of it tomorrow otherwise.
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
