Continuing the discussion from Easyform download of saved data includes HTML (!):
I suspect that something in the stack between waitress outputting a response and the content of what easyform wants to send is providing incorrect information or is missing it outright.
I'm looking for help from anyone who has had time to poke around inside waitress...
The discussion on github, especially downloading saved data should not include HTML of the form · Issue #175 · collective/collective.easyform · GitHub , makes it very unlikely that waitress is to blame. Almost surely, easyform or z3c.form is the culprit. Explaining the content of the comment mentioned above a bit further: the normal behaviour of a form after an action is to rerender the form (unless the action tells that this should not be done, e.g. by redirecting to somewhere else). In your case, the download action apparently generates the CSV (writing the response, maybe using Response.write) but forgets to tell the form that it should not rerender. Therefore, the form renders adding to the response. Before data can actually be sent to the browser, the headers, including Content-Length must be generated. Thus, the first Response.write will generate the headers (likely the download action has set this header); if afterwards additional output is produced for the response, waitress logs a warning.
Thanks, Dieter! That helps a lot. I didn’t know any of that 
I suppose I will look at how PloneFormGen does it and try to spot what's missing
I've got a PR in progress and am trying to fix Travis 
https://github.com/collective/collective.easyform/pull/204 - thank you @mamico!
I find it really disconcerting that no one else noticed that saved data downloads weren't working with EasyForm. Does no one actually use the save data action?
I really depend on the save data adapter, but hadn't noticed things because a lot of sites are still on Python2.7, for reasons...
(one day I'll find time to properly port collective.isotope...)
Down to 1 test failure:
File "/home/travis/build/collective/collective.easyform/src/collective/easyform/tests/attachment.rst", line 203, in attachment.rst
Failed example:
browser.getControl("Apply changes").click()
...
File "/home/travis/buildout-cache/eggs/ZODB-5.5.1-py3.7.egg/ZODB/serialize.py", line 439, in _dump
self._p.dump(state)
_pickle.PicklingError: Can't pickle <class 'z3c.form.interfaces.NOT_CHANGED'>: it's not the same object as z3c.form.interfaces.NOT_CHANGED
The test failure occurs with Plone 5.2, whether Python 2.7 or 3.6 or 3.7. I'm inclined to merge the PR but fixing the test needs someone who has more insight into the pickling changes that went into Plone 5.2
(in other words, the same tests pass for Plone 5.0 and 5.1)
At Six Feet Up (and perhaps elsewhere?) we have a saying, that you have to let the universe know what you need, and then sometimes it delivers...
... and a nice easy way to test the new release:
docker run -p 8080:8080 -e ADDONS="collective.easyform" -e VERSIONS="collective.easyform=2.1.4" plone fgI assume that your "pickling changes" refers to the pickling error in the preceding post. But I expect that this can be explained without pickling changes: this error occurs (and occurred already for a long time) when the object's class reference (i.e. obj.__class__) is different from the class object obtained via a fresh import: pickle will represent a class reference as a "global object", i.e. a pair module path, name. If the object corresponding to such a "global object" can change, then the pickle representation is not safe. The error informs about this unsafeness.
I have often seen those errors when I have reloaded modules. It can also occur with monkey patching or dynamically created classes.