GET response without ETag
@SvenF: I already guessed if my hoster maybe also did an Upgrade of Apache (or something else). And I also tried to enable ETag in .htaccess, but also without success
I opened a ticket at my hosters support website a few minutes ago. Usually they reply within 1 day. So let’s wait
Just out of curiosity: Since when do you have this issues? And what’s your hoster?
As far as I can remember I have the problem since about 16th august. My OwnCloud is hosted at Profihost (www.profihost.com)
Yes, Profihost is my provider. I also made a ticket for this and they told me the way to htaccess.
oh man, this starts to get annoying ;-/
somewhere I read, that gzip also could remove the ETag… found a lot of “solutions” how to disable gzip via .htaccess… but none of them worked for me… Or I did something wrong?
@mpausch gzip shouldn’t change the ETag, becaues the resources are normally not real static files (which would be sent by the Web server directly), but virtual resources generated by the CalDAV/CardDAV server (which manages the ETags, too).
Did you have any further progress related to this problem?
I am nearly daily in contact with my Provider but the problem still exists. I don’t know how to set ETag since the webserver has been updated to Apache 2.4.
ETagshould normally be set by the CalDAV/CardDAV server (OwnCloud?), not by the Web server. The only thing I can imagine is that the Web server (or maybe an application-level firewall?) removes the
ETagsent by OwnCloud.
like SvenF I also was in daily contact with my provider (which is the same provider as SvenF’s provider g).
Yesterday they solved the issue for me by “installing an update”.
Don’t know yet what this “update” actually was (software update? / configuration change?) but I asked if he could tell me. So hopefully I will know more within the next days Stay tuned, I will post feedback here.
OK - also I got the message of this update. In my case, it did not change the error.
- Do you have an htaccess entry for ETag. Which entry and where?
- Do you use ssl-proxy (sslkundenserver.de)?
No, don’t have an ETag entry in .htaccess.
And I don’t use ssl-proxy/sslkundenserver.de… (by the way: what’s that and how does that work?)
I’m using an SSL Proxy for connecting to the cloud with a shared SSL connection. So the transfer is more secure. Look at the webspace description at the Providers Homepage. Maybe in my case, the reason for the error is this connection. I asked the provider about this possibility.
mpausch last edited by mpausch
got feedback from support:
due to the update to Apache 2.4 hoster configured
Header unset ETag
in the global apache configuration.
According to the HEADER directive in the apache docs :
“… The header is modified just after the content handler and output filters are run, allowing outgoing headers to be modified. …”
So ETag header was generated by OwnCloud/PHP but then removed my mod_header
Hoster removed “Header unset ETag” from apache config. Now it works.
@SvenF : already contacted support to set up ssl-proxy for my domain. When it’s done I will test calendar/contact sync via ssl and post feedback here
Good to know that it now works and what has caused the problem. At least DAVdroid’s error message was correct
Do you know why they have removed ETags?
They removed the ETag header for “security reasons”.
Can’t imagine any risk that a ETag can have, but I’m not a security expert… so maybe I just don’t know any better
@SvenF : tried to set up a separate OwnCloud that I can access via sslkundenserver.de, but for some reasons it always redirects to http://www.mydomain.tld/owncloud instead of staying in https://sslkundenserver.de/www.mydomain.tld/owncloud
It’s OwnCloud and not DavDroid but I hope it’s OK in this thread…
I had in my OwnCloud config.php
- www.sslkundenserver.de in trusted_domains array
- ‘overwrite.cli.url’ => ‘https://www.sslkundenserver.de/myownclouddomain/myownclouddir’
- ‘overwritehost’ => ‘www.sslkundenserver.de’,
- ‘overwriteprotocol’ => ‘https’,
- ‘overwritewebroot’ => ‘/myownclouddomain/myownclouddir’,
- ‘overwritecondaddr’ => ‘^xx\.xxx\.xxx\.xxx$’, //IP from your Domain
This is a part of the config I have used. I’m very interested about your experience. In my case, there are no errors without SSL Proxy, but not possible with the SSL which I want to use for connect.
hm, for some reason I’m too dumb to get OC running via sslkundenserver.de…
even with your lines from config.php it kept redirecting to http
But I made another test. And from the results it seems for me like the proxy on sslkundenserver.de removes the ETag header. So the host that hosts your OC generates the ETag header and delivers it to the ssl-proxy… but then the proxy removes it…
My test was to retrieve a jpg from my webspace with curl and let the headers write into a simple textfile.
If you’re on Linux you can reproduce it with curl command. If not you also can reproduce it via ssh access to your webspace:
retrieve image via https and sslkundenserver.de:
curl -D headers_https.txt https://www.sslkundenserver.de/www.mydomain.tld/test/image.jpg > image_https.jpg
This will save the jpg on the one hand in file image_https.jpg and on the other hand in file image_http.jpg
In the headers*.txt files you will see the headers that were transferred between client (curl) and server.
[user@host davdroid-tests]$ ls -la headers_http*
-rw-r–r-- 1 user user 208 13. Sep 21:12 headers_https.txt
-rw-r–r-- 1 user user 271 13. Sep 21:11 headers_http.txt
[user@host davdroid-test]$ grep -i etag headers_http*
—> so the header only was retrieved via http…
So - final message.
It is fixed also with SSL Proxy.
They removed “Header unset ETag” from SSL Proxy. Now I use “FileETag -INode +MTime +Size” in htaccess and everything works fine - also with access over SSL-Server.
c13po last edited by
Oh my god!
I just registered here to say: Thank you so much! I was struggeling with this problem for too long. I contacted bitfire in the past but they kept telling me that this would be an owncloud problem. They told me to wait until Owncloud 9 and all the problems would be gone because they completely reimplemented the calendar/contact stack for OC 9,
However, after upgrading to OC 9 the problems remained. Just now I realized that it is an apache issue. Why the frack did they turn off ETags by default in 2.4?
In this thread they say that they didn’t change anything about etags in davdroid, but this is wrong. The support told me that they actually changed the behaviour after version 0.8.something. So I kept using this version before I read the solution on this thread.
Again, thank you!