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

Sergey Beryozkin commented on CXF-3879:
---------------------------------------

for JAXRS these classes are tested indirectly in 
systest/jaxrs/JAXRSMultipartProvider test, for JAXWS - in MTOM related tests in 
systest/jaxws.

The patch looks good - can you please recreate it against the trunk ?
And move throwing WebApplicationException to 
org.apache.cxf.jaxrs.provider.MultipartProvider.readFrom,
try {
List<Attachment> infos = 
            AttachmentUtils.getAttachments(mc, attachmentDir, 
attachmentThreshold); 
} catch (CacheSizeExceededException ex) {
   throw new WebApplicationException(413);
}

as in SOAP case it will have to be 500...

Unfortunately I won;t have time today to recreate the patch against the trunk - 
so if you can do it then shortly then I might be able to apply later this 
evening or may be Dan can do it later if he is OK with the changes, thanks
                
> Add the ability to enforce a maximum attachment size
> ----------------------------------------------------
>
>                 Key: CXF-3879
>                 URL: https://issues.apache.org/jira/browse/CXF-3879
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS
>    Affects Versions: 2.2.12, 2.3.7, 2.4.3
>            Reporter: Sam Meder
>         Attachments: attachment-size-limit.patch
>
>
> Safe handling of multipart-* HTTP request requires the ability to cap the 
> size of the uploaded attachments before they get cached. CXF does currently 
> not provide an option for this (other frameworks such as the commons 
> fileupload and the 3.0 servlet spec do provide this). I've attached a quick 
> patch that allows one to set a option for enforcing a size limit while doing 
> the attachment parsing (similar to the threshold and temp dir options). The 
> biggest question imo is how to best bubble up a appropriate error. I chose to 
> subclass IOException and then later on transform it into a 413 (request size 
> too large) HTTP response, but would welcome input on other approaches.
> I will attach a patch against CXF 2.2, but believe that it should also apply 
> to newer versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to