[
https://issues.apache.org/jira/browse/WICKET-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg resolved WICKET-1861.
-----------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.4-RC2)
1.4-RC3
the check now looks like this:
if (requestSize == -1 && getSizeMax() != Long.MAX_VALUE)
if you have it set to max then obviously you dont care how big it is - so
knowing the size ahead of time doesnt really matter.
yes this is a caucho problem because they dont set the right headers or
whatever, but we can also handle it if it makes sense.
> Inevitable UnknownSizeException with HTTPS
> ------------------------------------------
>
> Key: WICKET-1861
> URL: https://issues.apache.org/jira/browse/WICKET-1861
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-M3
> Environment: Caucho Resin 3.2 behind apache2
> Reporter: uwe schaefer
> Assignee: Igor Vaynberg
> Fix For: 1.4-RC3
>
>
> When using a FileUploadField in a HTTPS environment, the request always
> returns a request-size of -1.
> In that case, FileUploadBase rejects to process the reuqest, no matter what
> (or if) a maxSize is defined:
> org.apache.wicket.util.upload.FileUploadBase:236 (wicket 1.4m3)
> if (requestSize == -1) {
> throw new UnknownSizeException( "the request was rejected because its size
> is unknown");
> }
> this makes it impossible to use fileUploads with HTTPS in this environment at
> all.
> I think, this _sanity check_ should not be done if either HTTPS is used, or
> the developer does not care (expressed by not setting any maxSize).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
