commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinicius da Costa Pires (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FILEUPLOAD-197) ServletFileUpload isMultipartContent method does not support HTTP PUT
Date Thu, 26 Feb 2015 18:25:05 GMT

    [ https://issues.apache.org/jira/browse/FILEUPLOAD-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338857#comment-14338857
] 

Vinicius da Costa Pires commented on FILEUPLOAD-197:
----------------------------------------------------

Hi, Simone, Roy and Jochen. I know this is an old discussion, but I just wanted to add a thought
on this, to see if you agree with me...

I agree with you and Roy that ASF has a bigger role in the scene, and that many frameworks
like Spring rely on stable architectural code as the Commons File Upload project, and to accomplish
that stability and cleaness you should stick to the specs.

But you have to agree with me that the thing here is not about accepting PUT, POST, PATCH
or whatever method someone is using, it's about a concise architectural code that does exactly
what is expected of it.

If the purpose of the "ServletFileUpload.isMultipartContent" method is to verify if the "HttpServletRequest"
object has a multipart content type and therefore the request is multipart, shouldn't this
method only verify that and exit? What is that "if" doing there? Is it checking if request
has content? If it's preventing a problem that we can't see, maybe it could be the same "if",
but checking the right thing, like "if the request method is the kind of method that has content"...

And as David stated in his comment, neither POST and PUT specs are clear about the content
type, if it's form-data, multipart, json, xml, or any other content. HTTP was designed to
not opinionate on content type, am I right?

I understand this requires a certain amount of work for everybody, but all around the web
in forums and sites like StackOverflow, this method haunts every HTTP1.1 java API developer,
and the only choices are either not PUT or PATCH files to the server, or not using Commons
FileUpload at all. Implementing a way to .zip the file just to upload on PUT and PATCH requests
in javascript for me is out of question.

I personally like ASF's work and trust the stability of its packages, so I don't think that
implementing my own "isMultipartContent()" is the way to go (although it's my only choice
now with the tight schedule).

I hope that my comment helps with something. Thanks for your time.

> ServletFileUpload isMultipartContent method does not support HTTP PUT
> ---------------------------------------------------------------------
>
>                 Key: FILEUPLOAD-197
>                 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-197
>             Project: Commons FileUpload
>          Issue Type: Bug
>    Affects Versions: 1.2.2
>            Reporter: David Wolverton
>            Assignee: Simone Tripodi
>             Fix For: 1.3
>
>
> This method explicitly checks for method POST. I believe the PUT method can also have
multipart requests, and there may be others. In our case we are receiving rest calls using
Spring Framework's CommonsMultipartResolver which in turn uses this method of the Commons
FileUpload library.
> Here is the offending code...
> if (!"post".equals(request.getMethod().toLowerCase())) {
>     return false;
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message