Release 6.5.0 corrupts uploads

Hello,

:what:
[b]

due to bug http://dev.vaadin.com/ticket/6361 I think it is
very important to get either that 6.5.1 release out as soon as possible.
[/b]

Or perhaps just release a 6.5.0a which only includes that fix.

The problem with that error is, that every user using vaadin to upload files
on a server will corrupt the uploads, often without noticing it.

I think this is really a more critical than a “blocker” bug.

:what:

André

To get a working upload until 6.5.1 is released (scheduled for later this week) you can use the latest 6.5.1 nightly which should be as stable as 6.5.0.

Yep,

it’s what I have done now.

But I think for that type of bug 14 days is too long, especially since it has not been mentioned in the forum.

This particular bug can cause data corruption which you don’t see when it occurs.
For example when uploading .doc, .xls or .csv files, you won’t notice it.

I did only stumble over it, because a user reported that they could not upload .jpg files.
(I generate automatically thumbnails from the uploaded file, and this process then failed…)

André

Hmmm…

is it possible that this problem existed since 6.4.8 ?

The code where the bug existed was refactored and partly rewritten for 6.5 so no, the same bug is not in 6.4.8.

HI,

not sure if this is related, but once we moved from 6.4 to latest 6.5.3 the upload component does not work with SSL-connection, but works fine without SSL.

With SSL, the upload component doesn’t start downloading files, instead it seems as if nothing happens and also server doesn’t receive receiveUpload - event.

Does the 6.5 version require special settings for SSL, or is this a bug?

Hi,

I tried to reproduce the issue but upload on ssl works fine for me. I tried with 6.6-nightly, but it shouldn’t make a difference as we haven’t worked on that area for a while. If you provide some details about your environment I could have a change to check out what is going wrong. Server, os, browser, java version etc.

cheers,
matti

our setup is tomcat on linux and the problem exists atleast on firefox and chrome on windows and linux.

reverting back to 6.4.8 seemed to fix the issue!

Hi,

Works fine on tomcat for me. I ran the test on mac but I’d be surprised if that is the issue. I guess it is some sort of hosting detail that is causing your issue. Maybe you have a some sort of front end server that is providing SSL? If I can’t reproduce the issue there is pretty much nothing I can do with these details. My tomcat version was 6.0.18. My ssl connector setting I used for testing:


    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" keystoreFile="/Users/mattitahvonen/Documents/ws_toolkit/trunk1/src/com/vaadin/launcher/keystore"
keystorePass="password" />

cheers,
matti

we tried with your suggestion, of couse with right keystore and password but no change. Here are further details:

tomcat version 5.5.27 with apache

ssl has been configured in apache and tomcat connector configuration has not been needed for https-connection.

6.4.8 works with these settings.

we got new information regarding 6.5.3:

  • browser sends data into server (chrome shows percentage of file upload progress)
  • none of the upload - component events are raised, not event upload failed
  • firefox gives following warning to user after send -button has been clicked

Tämä sivu on salattu, mutta sivulliset voivat helposti lukea sille kirjoitetut tiedot koska ne lähetetään salaamatta.

Lähetetäänkö nämä tiedot?\

seems like something has been changed with 6.5.3 version.

does this give you any ideas where to look for an solution?

Luckily I know some Finnish :slight_smile:

Mixed content warnings must be coming if the Upload component is posting the content into non ssl target from a properly secured host page. I just checked that this may happen if your applications getURL() returns non-ssl address.

I’d see there are three apparent places where this could go wrong:

  • some detail in hosting configuration makes the servlet think it is non-ssl (probably the front end configuration somehow).
  • You have overrided application getUrl to always return non-ssl address
  • The session is created (application is started) on non-ssl side and then switched to ssl protected version. I’m not 100% sure, but it looks to me that Vaadin don’t support this properly (appUrl is set on start and never changed). You may call it a bug or missing feature.

All these will most likely also cause some other mixed content warning issues if you use for eg. applicaiton resources (also in 6.4 series). So I’d suggest to fix the setup somehow and then move to 6.5.LATEST. If you are only allowing ssl connections, the easieast and quickest workaround is to override getUrl() in your Application class in a way that it always returns https://foo.bar/myapp instead of http://foo.bar/myapp.

If the issue is the last of the tree, I’ll promise it will get sooner fixed if you fill a nice ticket into our trac.

Instructions for nice tickets.

cheers,
matti

Thanks for those three pointers.

we did some digging and found that we have some code related to url.

we dont use setURL-method, but we do use setLogoutURL, which we force to https- mode because even though browser url-bar says:

https://aes.adensy.com/episteme/production/default

vaadin sees the real, non-ssl address which is:

http://odcust24.louhi.net:8080/episteme/production/default

so, to make sure that logout redirect to ssl-address, we change the logoutUrl from non-ssl to ssl address by using setLogoutUrl

so, it seems like we are getting closer. So, should we use setURL-method when application starts to force it to https-address? Is that the right place?

We can try this out next weekend and see the results. Few advices on how to use setUrl and if there are any things to consider would be great before that.

if this is the solution, could it be that there is a change in upload component on how it determines the right address? 6.4 does seem to use the https-address found on browser url-bar.

thanks!

Hi,

Application does not have setURL method, but I think you can pretty easily override the getter. Replacing the start of the url with https instead of http should work. Hardcoding the actual deployment url might be bad for maintainability. In case your app server itself provides no ssl, you might though lose the ability to test directly from the app server.

In Vaadin 6.4 the url for upload post was derived from on the client side, but that was a no-go for e.g. some portals. I’m sure we can fix this into 6.5, but I’d like to fix in in the right way (and not brake those portals that now work flawlessly).

cheers,
matti

We also have this issue since 6.5.

Application deployed in tomcat, behind apache reverse-proxy with https. The upload componant generates a form with http instead of https.

HI David and Matti,

overloading the getUrl method in the application class worked for us, so that might work for you David as well.

for us, it would be better if client side engine would workout the right address, since our application can be used both https protocol and without.

it required that we did some tricks to determine which protocol to return to client and such tricks are always prone to error.

Would this have done the trick:
((WebBrowser)window.getTerminal()).
isSecureConnection()

Do you run plain http between the proxy and the Tomcat server as the application url is generated as “http://” or “https://” depending on if the request to the servlet is secure or not (using HttpServletRequest.isSequre).

Hi,

To make Vaadin work perfectly it would be best to tune the proxy/app server setup so that the request returns correct values for isSecure(). There are some workarounds discussed in
#6643

In latest nightly builds uploads should work again, even without tuning your proxy setup. Also ApplicationResource’s should work (probably the first time ever with Vaadin and this kind of reverse proxy setup). Would you try with the latest nightly build and report if there is still an issue in
#6772
?

cheers,
matti

Sadly, the
#6772
in 6.5.5 seem to broke a possibility of using CustomStream to serve streams / files.

Pretty common practice like …

getApplication().getMainWindow().open(new MyStreamResource(...))

… now makes browser manage to open URL “app://APP/1/myfile.csv” instead of former “BASE_URL/VaadinApp/APP/1/myfile.csv”. Was that really intended? Thanks.

Honestly, no. It would be great if we had a community that would use nightly builds. There is just too many features in Vaadin that can be broken easily. At least with my skills.

Thanks for bringing this up. Later better than never. Ticket link below:

http://dev.vaadin.com/ticket/6849

cheers,
matti