If I set 'WSGIChunkedRequest On' in Apache config, I now get a traceback from Radicale in ssl_error_log:

[Wed Sep 13 19:15:35.280628 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39856] GET request at /adamw/Personal.ics/514dec98e105a00807d64f3b3d5d9a4828459301.ics received
[Wed Sep 13 19:15:35.300320 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39858] GET request at /adamw/Personal.ics/514dec98e105a00807d64f3b3d5d9a4828459301 received
[Wed Sep 13 19:15:35.319997 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860] PUT request at /adamw/Personal.ics/514dec98e105a00807d64f3b3d5d9a4828459301.ics received
[Wed Sep 13 19:15:35.335016 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860] mod_wsgi (pid=32240): Exception occurred processing WSGI script '/usr/share/radicale/radicale.wsgi'.
[Wed Sep 13 19:15:35.337312 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860] Traceback (most recent call last):
[Wed Sep 13 19:15:35.337342 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]   File "/usr/lib/python3.6/site-packages/radicale/__init__.py", line 332, in __call__
[Wed Sep 13 19:15:35.337345 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]     user)
[Wed Sep 13 19:15:35.337349 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]   File "/usr/lib/python3.6/site-packages/radicale/__init__.py", line 588, in do_PUT
[Wed Sep 13 19:15:35.337351 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]     xmlutils.put(environ["PATH_INFO"], content, collection)
[Wed Sep 13 19:15:35.337354 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]   File "/usr/lib/python3.6/site-packages/radicale/xmlutils.py", line 453, in put
[Wed Sep 13 19:15:35.337358 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]     collection.append(name, ical_request)
[Wed Sep 13 19:15:35.337361 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]   File "/usr/lib/python3.6/site-packages/radicale/ical.py", line 357, in append
[Wed Sep 13 19:15:35.337363 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]     text, (Timezone, Event, Todo, Journal, Card), name)
[Wed Sep 13 19:15:35.337367 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]   File "/usr/lib/python3.6/site-packages/radicale/ical.py", line 324, in _parse
[Wed Sep 13 19:15:35.337368 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]     lines = unfold(text)
[Wed Sep 13 19:15:35.337372 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]   File "/usr/lib/python3.6/site-packages/radicale/ical.py", line 63, in unfold
[Wed Sep 13 19:15:35.337373 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]     return re.sub('\\r\\n( |\\t)', '', text).splitlines()
[Wed Sep 13 19:15:35.337382 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]   File "/usr/lib64/python3.6/re.py", line 191, in sub
[Wed Sep 13 19:15:35.337384 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860]     return _compile(pattern, flags).sub(repl, string, count)
[Wed Sep 13 19:15:35.337395 2017] [wsgi:error] [pid 32240:tid 139724945602304] [remote 192.168.1.5:39860] TypeError: expected string or bytes-like object

Thanks for a bug report. Looking into the headers being sent to the server, they are the same as with 3.24.5, only the latest version has these added:

> Cache-Control: no-cache
> Pragma: no-cache
> Transfer-Encoding: chunked

The new version also changes the way it has constructed the Content-Type header, but I do not think it has any impact on the issue. The old version uses:
> Content-Type: text/calendar; charset=utf-8
while the new version uses:
> Content-Type: text/calendar; charset="utf-8"

I'm pretty sure it's the Transfer-Encoding header which your server gets confused with. Looking into the description of the "chunked" encoding [1], it's either libsoup doing things in a way which Radicale doesn't understand (other servers like Google, DAViCal, Zimbra, Yandex, GMX,... have no issue with it) or the Radicale server has some bug in the chunked transfer encoding algorithm. [2]

I tried to configure radicale server on my machine, but no luck. I didn't try too hard, and I'm not an httpd expert either, which may explains things (it says Forbidden, when I try to access the virtual host, even the httpd successfully verifies my credentials). By the way, what is your radicale server version, please?

[1] https://tools.ietf.org/html/rfc2616#section-3.6.1
[2] https://tools.ietf.org/html/rfc2616#section-19.4.6

I'm on 1.1.6. 2.x is packaged for F27+ but not for F26.

I'm on vacation ATM, but I'll try and send you details of my Radicale config a bit later...

Do you know *why* libsoup / evo has changed to request chunked transfers?

(In reply to Adam Williamson from comment #3)
> Do you know *why* libsoup / evo has changed to request chunked transfers?

I did it, kind of generalized use of streams. When writing EWebDAVSession and dealing with uploads I had on mind that people may eventually upload gigabytes of data, thus instead of loading it into the memory and trying to push it at once I decided to use the chunked API of libsoup. It's not needed for such small data like events, usually, but the code reuses the chunk API for consistency and simpler maintenance (instead of having two code branches for upload there's only one).

I managed to run Radicale locally and I can reproduce it too. The problem is in Radicale itself, they do not support chunked transfer encoding for some reason. Open:
   /usr/lib/python3.6/site-packages/radicale/__init__.py
and search for "CONTENT_LENGTH" there. They rely on it and they do not check for "HTTP_TRANSFER_ENCODING" value. I would expect something like:

        elif environ.get("HTTP_TRANSFER_ENCODING").upper() == "CHUNKED":

in that content reading part, but it's not there. Maybe they would be able to use something from wsgi [1], but python is not my language, thus I do not know how to do that.

I also had a look into the Radicale 2.1.6 sources and they have there a change in this part, they use (and define) _read_raw_content() now, but it still doesn't understand the chunked transfer encoding. Furthermore, they return empty string instead of None, which can have bad side effects, like silently putting empty components, instead of failing with (runtime) error. I didn't try it in action, thus it's possible the code fails gracefully on later checks, like when verifying that the content conforms to the expected collection data type.

You might ask them to add support for chunked transfer encoding. While I can change it on the eds side too, I would be unhappy to do it, for the reason from the top of this comment (large file upload). It's the only server (at the moment) which doesn't work with this, with compare of many other (I forgot to mention also ownCloud/nextCloud and Yahoo! in the list of tested servers).

[1] http://uwsgi-docs.readthedocs.io/en/latest/Chunked.html

*** Bug 788176 has been marked as a duplicate of this bug. ***

I'm reopening this. The bug above mentions a different server having trouble with the chunked Transfer-Encoding, thus I'll try to find some solution, the worse to use that chunked encoding only for stream and use the old way for non-stream PUTs (thus two code paths instead of one, as mentioned above).

I do not see anything other to use for the long streams, thus I copied part of the code to the other function which uses in-memory data. That is also used in both CalDAV and CardDAV, thus it fixes the issue.

Created commit 85543d399 in eds master (3.27.1+)
Created commit ef8b553fd in eds gnome-3-26 (3.26.1+)

It's fixed for my university Zimbra server, thanks ;)

*** Bug 788239 has been marked as a duplicate of this bug. ***

Fix confirmed here with 3.26.1, thanks.

*** Bug 789158 has been marked as a duplicate of this bug. ***

Hello, is there something wrong with the 3.26.1 tarball?

ArchLinux is using git commit=cfd2bdb29f5bbb8b6cad90072011b23753122616 to build it package, bug is fixed.

Fedora 27 use 3.26.1 tarball and bug is not fixed.

(In reply to Cédric Bellegarde from comment #12)
> Hello, is there something wrong with the 3.26.1 tarball?

No, I do not think so. Tarballs are generated from (and by) git checkout.

> Fedora 27 use 3.26.1 tarball and bug is not fixed.

How did you install and test it, please? Adam uses Fedora and confirmed the fix at comment #10. If you verified it's broken, then installed new eds and tried to verify it's fixed, without restarting background processes (where the change had been done), then you've been still using old bits.