-
I have Deliverance running on top of the standard Plone theme. (actually the Plone Tableless theme). The complete setup looks like this Apache in front with mod_deflate to do HTTP Compression Deliverance doing the themeing voodoo that it do Plone 3.17 Everything seems to work reasonably well except Kupu. Kupu (stock version that ships with Plone 3.17) will load fine only after I created the following rules in the deliverance.xml file: <proxy path="contains: emptypage" class="emptypage"> <dest href="http://127.0.0.1:8080/" /> </proxy> <rule class="emptypage"> <replace content="element:/html/head" theme="element:/html/head" /> <replace content="element:/html/body" theme="element:/html/body" /> </rule> This rule was necessary because the hint in emptypage.pt (<meta http-equiv="x-deliverance-no-theme" content="1">) doesn't seem to prevent Deliverance from applying the theme. When switching into Plone's edit mode, Kupu loads fine and all the controls and windows load and populate with all the existing data. Edits can be made on screen and the Submit button sends a POST back to Apache, but the response I can bypass the Apache and hit Deliverance directly. Still, Kupu loads fine but saves don't commit. I wonder if the order of elements in the head are being reorganized in a way that is incompatible with Kupu. Any ideas would be appreciated. Thanks, Don Fick don@...
- Thread Outline:
-
- Re: Kupu won't save through Deliverance by ianb
-
One problem people have had with Kupu is that it looks for the Zope-specific use of a <base> tag to identify the location of the object (instead of location.href or something). If you configure Deliverance to rewrite links (<response rewrite-links="1" /> then it will eliminate the <base> tag. I think people have gotten it to work just by adjusting that configuration. On Mon, Jun 29, 2009 at 9:00 PM, Don Fick<don@...> wrote: > I have Deliverance running on top of the standard Plone theme. (actually the Plone Tableless theme). > > The complete setup looks like this > > Apache in front with mod_deflate to do HTTP Compression > Deliverance doing the themeing voodoo that it do > Plone 3.17 > > Everything seems to work reasonably well except Kupu. > > Kupu (stock version that ships with Plone 3.17) will load fine only after I created the following rules in the deliverance.xml file: > > <proxy path="contains: emptypage" class="emptypage"> > <dest href="http://127.0.0.1:8080/" /> > </proxy> > <rule class="emptypage"> > <replace content="element:/html/head" theme="element:/html/head" /> > <replace content="element:/html/body" theme="element:/html/body" /> > > </rule> > > This rule was necessary because the hint in emptypage.pt (<meta http-equiv="x-deliverance-no-theme" content="1">) doesn't seem to prevent Deliverance from applying the theme. > > When switching into Plone's edit mode, Kupu loads fine and all the controls and windows load and populate with all the existing data. Edits can be made on screen and the Submit button sends a POST back to Apache, but the response > > I can bypass the Apache and hit Deliverance directly. Still, Kupu loads fine but saves don't commit. > > I wonder if the order of elements in the head are being reorganized in a way that is incompatible with Kupu. > > Any ideas would be appreciated. > > Thanks, > Don Fick > don@... > > > -- > Archive: http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/06/1246327237306 > To unsubscribe send an email with subject "unsubscribe" to deliverance-devel@.... Please contact deliverance-devel-manager@... for questions. > > -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
-
I actually have the same problem with a PloneFormGen-generated form. I'm applying no themeing right now and have link rewriting on, but pressing the "submit" button results in a POST showing up in my Zope access log, and getting ignored. The form works fine from the native Plone interface or through an Apache proxy, however. On Jul 01, 2009 12:27 PM, Ian Bicking wrote: > One problem people have had with Kupu is that it looks for the > Zope-specific use of a <base> tag to identify the location of the > object (instead of location.href or something). If you configure > Deliverance to rewrite links (<response rewrite-links="1" /> then it > will eliminate the <base> tag. I think people have gotten it to work > just by adjusting that configuration. > > > On Mon, Jun 29, 2009 at 9:00 PM, Don Fick<don@...> wrote: > > I have Deliverance running on top of the standard Plone theme. (actually > > the Plone Tableless theme). > > > > The complete setup looks like this > > > > Apache in front with mod_deflate to do HTTP Compression > > Deliverance doing the themeing voodoo that it do > > Plone 3.17 > > > > Everything seems to work reasonably well except Kupu. > > > > Kupu (stock version that ships with Plone 3.17) will load fine only after > > I created the following rules in the deliverance.xml file: > > > > <proxy path="contains: emptypage" class="emptypage"> > > <dest href="http://127.0.0.1:8080/" /> > > </proxy> > > <rule class="emptypage"> > > <replace content="element:/html/head" > > theme="element:/html/head" /> <replace > > content="element:/html/body" theme="element:/html/body" /> > > > > </rule> > > > > This rule was necessary because the hint in emptypage.pt (<meta > > http-equiv="x-deliverance-no-theme" content="1">) doesn't seem to prevent > > Deliverance from applying the theme. > > > > When switching into Plone's edit mode, Kupu loads fine and all the > > controls and windows load and populate with all the existing data. Edits > > can be made on screen and the Submit button sends a POST back to Apache, > > but the response > > > > I can bypass the Apache and hit Deliverance directly. Still, Kupu loads > > fine but saves don't commit. > > > > I wonder if the order of elements in the head are being reorganized in a > > way that is incompatible with Kupu. > > > > Any ideas would be appreciated. > > > > Thanks, > > Don Fick > > don@... > > > > > > -- > > Archive: > > > > http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/06/1246327237306 To > > unsubscribe send an email with subject "unsubscribe" to > > deliverance-devel@.... Please contact > > deliverance-devel-manager@... for questions. > > > > > > >
-
@Ian: A good tip but rewrite links is definitely not present. @Matt: Likewise I see some of the same problems when trying to use plone_control_panel functions through Deliverance, such as /@@site- controlpanel. I setup a completely fresh install of Plone 3.17 (default theme) and a very simple Deliverance rules file. The key parts of the Deliverance rule file are" <proxy path="/"> <dest href="http://127.0.0.1:8080/VirtualHostBase/http/donfick.com:8085/deltest/VirtualHostRoot " /> </proxy> <rule suppress-standard="1"> <replace content="element:/html/head" theme="element:/html/head" /> <replace content="element:/html/body" theme="element:/html/body" /> </rule> So there is no <response rewrite-links="1" /> The pages server out of Plone and through Deliverance with no problem. Both sites look exactly the same. Kupu loads without a problem. I have done diff comparisons and the only difference between the HTML "direct-from-Plone" and "through-Deliverance" is the hostname paths in the href attributes due to virtual host monster. When a full page Kupu POST goes straight to Plone, the server responds with a 302 and the browser loads the redirect without a problem and the changes are saved. When a full page Kupu POST goes to Deliverance, the Plone server responds with a 200 and the content contains a full HTML page. The HTML is the full, original edit page HTML without the edits. Zope log file snippets appear below. This problem doesn't affect all POSTs. The Plone commenting function works without a problem. Is there an option to increase the logging level in Zope/Plone? Nothing related to this appears in the instance.log and nothing appears in the ZMI error_log. Thanks, Don ---------------------- Standard Plone This is a successful edit with content stored in Plone: Zope instance-Z2.log following a POST directly to Plone. The server responds with a 302 and the browser loads the redirect without a problem and the changes are saved. 74.183.224.6 - Anonymous [02/Jul/2009:13:08:53 +0000] "POST /deltest/ front-page/atct_edit HTTP/1.1" 302 389 "http://slice1.donfick.com:8080/deltest/front-page/edit " "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11" 74.183.224.6 - Anonymous [02/Jul/2009:13:08:53 +0000] "GET /deltest/ front-page/@@plone_lock_operations/safe_unlock HTTP/1.1" 204 144 "http://slice1.donfick.com:8080/deltest/front-page/edit " "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11" 74.183.224.6 - Anonymous [02/Jul/2009:13:08:53 +0000] "GET /deltest/ front-page HTTP/1.1" 200 35985 "http://slice1.donfick.com:8080/deltest/front-page/edit " "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11" POST reponse header (Status-Line) HTTP/1.1 302 Moved Temporarily Server Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.7 Date Thu, 02 Jul 2009 13:53:11 GMT Content-Length 42 Content-Type text/plain; charset=utf-8 Location http://donfick.com:8080/deltest/front-page Set-Cookie statusmessages="AcRDaGFuZ2VzIHNhdmVkLmluZm8="; Path=/ --------------------------- With Deliverance in Front This is a failed edit: Zope instance-Z2.log following a POST through Deliverance. The server responds with a 200 where the content is HTML 127.0.0.1 - Anonymous [02/Jul/2009:13:01:52 +0000] "POST / VirtualHostBase/http/donfick.com:8085/deltest/VirtualHostRoot/front- page/atct_edit HTTP/1.1" 200 79486 "http://donfick.com:8085/front-page/edit " "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11" 127.0.0.1 - Anonymous [02/Jul/2009:13:01:52 +0000] "GET / VirtualHostBase/http/donfick.com:8085/deltest/VirtualHostRoot/front- page/@@plone_lock_operations/safe_unlock HTTP/1.1" 204 144 "http://donfick.com:8085/front-page/edit " "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11" POST reponse header (Status-Line) HTTP/1.0 200 OK Server PasteWSGIServer/0.5 Python/2.5.2, Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.7 Date Thu, 02 Jul 2009 13:53:47 GMT, Thu, 02 Jul 2009 13:53:47 GMT Expires Sat, 1 Jan 2000 00:00:00 GMT Content-Type text/html;charset=utf-8 Content-Language en-us Content-Length 79345 Don Fick don@... On Jul 1, 2009, at 3:12 PM, Matt Perry wrote: > I actually have the same problem with a PloneFormGen-generated > form. I'm > applying no themeing right now and have link rewriting on, but > pressing the > "submit" button results in a POST showing up in my Zope access log, > and > getting ignored. The form works fine from the native Plone > interface or > through an Apache proxy, however. > > On Jul 01, 2009 12:27 PM, Ian Bicking wrote: >> One problem people have had with Kupu is that it looks for the >> Zope-specific use of a <base> tag to identify the location of the >> object (instead of location.href or something). If you configure >> Deliverance to rewrite links (<response rewrite-links="1" /> then it >> will eliminate the <base> tag. I think people have gotten it to work >> just by adjusting that configuration. >> >> >> On Mon, Jun 29, 2009 at 9:00 PM, Don Fick<don@...> wrote: >>> I have Deliverance running on top of the standard Plone theme. >>> (actually >>> the Plone Tableless theme). >>> >>> The complete setup looks like this >>> >>> Apache in front with mod_deflate to do HTTP Compression >>> Deliverance doing the themeing voodoo that it do >>> Plone 3.17 >>> >>> Everything seems to work reasonably well except Kupu. >>> >>> Kupu (stock version that ships with Plone 3.17) will load fine >>> only after >>> I created the following rules in the deliverance.xml file: >>> >>> <proxy path="contains: emptypage" class="emptypage"> >>> <dest href="http://127.0.0.1:8080/" /> >>> </proxy> >>> <rule class="emptypage"> >>> <replace content="element:/html/head" >>> theme="element:/html/head" /> > <replace >>> content="element:/html/body" theme="element:/html/body" /> >>> >>> </rule> >>> >>> This rule was necessary because the hint in emptypage.pt (<meta >>> http-equiv="x-deliverance-no-theme" content="1">) doesn't seem to >>> prevent >>> Deliverance from applying the theme. >>> >>> When switching into Plone's edit mode, Kupu loads fine and all the >>> controls and windows load and populate with all the existing >>> data. Edits >>> can be made on screen and the Submit button sends a POST back to >>> Apache, >>> but the response >>> >>> I can bypass the Apache and hit Deliverance directly. Still, Kupu >>> loads >>> fine but saves don't commit. >>> >>> I wonder if the order of elements in the head are being >>> reorganized in a >>> way that is incompatible with Kupu. >>> >>> Any ideas would be appreciated. >>> >>> Thanks, >>> Don Fick >>> don@... >>> >>> >>> -- >>> Archive: >>> >>> http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/06/1246327237306 > To >>> unsubscribe send an email with subject "unsubscribe" to >>> deliverance-devel@.... Please contact >>> deliverance-devel-manager@... for questions. >>> >>> >> >> >> > > > > -- > Archive: http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246475576932 > To unsubscribe send an email with subject "unsubscribe" to deliverance-devel@... > . Please contact deliverance-devel-manager@... for > questions. >
-
If you want to see exactly what Deliverance sends to Zope, use --debug-headers. Use --debug-headers --debug-headers to show the bodies of the requests. It shows these on the console. You can match this up against LiveHTTPHeaders or what Firebug shows when you connect directly to Zope. This might reveal something. On Thu, Jul 2, 2009 at 9:27 AM, Don Fick<don@...> wrote: > @Ian: A good tip but rewrite links is definitely not present. > > @Matt: Likewise I see some of the same problems when trying to use > plone_control_panel functions through Deliverance, such as > /@@site-controlpanel. > > I setup a completely fresh install of Plone 3.17 (default theme) and a very > simple Deliverance rules file. > > The key parts of the Deliverance rule file are" > <proxy path="/"> > <dest > href="http://127.0.0.1:8080/VirtualHostBase/http/donfick.com:8085/deltest/VirtualHostRoot" > /> > </proxy> > <rule suppress-standard="1"> > <replace content="element:/html/head" > theme="element:/html/head" /> > <replace content="element:/html/body" > theme="element:/html/body" /> > </rule> > > So there is no <response rewrite-links="1" /> > > The pages server out of Plone and through Deliverance with no problem. Both > sites look exactly the same. Kupu loads without a problem. I have done diff > comparisons and the only difference between the HTML "direct-from-Plone" and > "through-Deliverance" is the hostname paths in the href attributes due to > virtual host monster. > > When a full page Kupu POST goes straight to Plone, the server responds with > a 302 and the browser loads the redirect without a problem and the changes > are saved. > When a full page Kupu POST goes to Deliverance, the Plone server responds > with a 200 and the content contains a full HTML page. The HTML is the full, > original edit page HTML without the edits. Zope log file snippets appear > below. > > This problem doesn't affect all POSTs. The Plone commenting function works > without a problem. > > Is there an option to increase the logging level in Zope/Plone? Nothing > related to this appears in the instance.log and nothing appears in the ZMI > error_log. > > Thanks, > Don > > ---------------------- > Standard Plone > > This is a successful edit with content stored in Plone: > Zope instance-Z2.log following a POST directly to Plone. The server responds > with a 302 and the browser loads the redirect without a problem and the > changes are saved. > 74.183.224.6 - Anonymous [02/Jul/2009:13:08:53 +0000] "POST > /deltest/front-page/atct_edit HTTP/1.1" 302 389 > "http://slice1.donfick.com:8080/deltest/front-page/edit" "Mozilla/5.0 > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > Firefox/3.0.11" > 74.183.224.6 - Anonymous [02/Jul/2009:13:08:53 +0000] "GET > /deltest/front-page/@@plone_lock_operations/safe_unlock HTTP/1.1" 204 144 > "http://slice1.donfick.com:8080/deltest/front-page/edit" "Mozilla/5.0 > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > Firefox/3.0.11" > 74.183.224.6 - Anonymous [02/Jul/2009:13:08:53 +0000] "GET > /deltest/front-page HTTP/1.1" 200 35985 > "http://slice1.donfick.com:8080/deltest/front-page/edit" "Mozilla/5.0 > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > Firefox/3.0.11" > > POST reponse header > (Status-Line) HTTP/1.1 302 Moved Temporarily > Server Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 > Plone/3.1.7 > Date Thu, 02 Jul 2009 13:53:11 GMT > Content-Length 42 > Content-Type text/plain; charset=utf-8 > Location http://donfick.com:8080/deltest/front-page > Set-Cookie statusmessages="AcRDaGFuZ2VzIHNhdmVkLmluZm8="; Path=/ > > --------------------------- > With Deliverance in Front > > This is a failed edit: > Zope instance-Z2.log following a POST through Deliverance. The server > responds with a 200 where the content is HTML > 127.0.0.1 - Anonymous [02/Jul/2009:13:01:52 +0000] "POST > /VirtualHostBase/http/donfick.com:8085/deltest/VirtualHostRoot/front-page/atct_edit > HTTP/1.1" 200 79486 "http://donfick.com:8085/front-page/edit" "Mozilla/5.0 > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > Firefox/3.0.11" > 127.0.0.1 - Anonymous [02/Jul/2009:13:01:52 +0000] "GET > /VirtualHostBase/http/donfick.com:8085/deltest/VirtualHostRoot/front-page/@@plone_lock_operations/safe_unlock > HTTP/1.1" 204 144 "http://donfick.com:8085/front-page/edit" "Mozilla/5.0 > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > Firefox/3.0.11" > > POST reponse header > (Status-Line) HTTP/1.0 200 OK > Server PasteWSGIServer/0.5 Python/2.5.2, Zope/(Zope 2.10.6-final, python > 2.4.5, linux2) ZServer/1.1 Plone/3.1.7 > Date Thu, 02 Jul 2009 13:53:47 GMT, Thu, 02 Jul 2009 13:53:47 GMT > Expires Sat, 1 Jan 2000 00:00:00 GMT > Content-Type text/html;charset=utf-8 > Content-Language en-us > Content-Length 79345 > > > Don Fick > don@... > > > > On Jul 1, 2009, at 3:12 PM, Matt Perry wrote: > >> I actually have the same problem with a PloneFormGen-generated form. I'm >> applying no themeing right now and have link rewriting on, but pressing >> the >> "submit" button results in a POST showing up in my Zope access log, and >> getting ignored. The form works fine from the native Plone interface or >> through an Apache proxy, however. >> >> On Jul 01, 2009 12:27 PM, Ian Bicking wrote: >>> >>> One problem people have had with Kupu is that it looks for the >>> Zope-specific use of a <base> tag to identify the location of the >>> object (instead of location.href or something). If you configure >>> Deliverance to rewrite links (<response rewrite-links="1" /> then it >>> will eliminate the <base> tag. I think people have gotten it to work >>> just by adjusting that configuration. >>> >>> >>> On Mon, Jun 29, 2009 at 9:00 PM, Don Fick<don@...> wrote: >>>> >>>> I have Deliverance running on top of the standard Plone theme. (actually >>>> the Plone Tableless theme). >>>> >>>> The complete setup looks like this >>>> >>>> Apache in front with mod_deflate to do HTTP Compression >>>> Deliverance doing the themeing voodoo that it do >>>> Plone 3.17 >>>> >>>> Everything seems to work reasonably well except Kupu. >>>> >>>> Kupu (stock version that ships with Plone 3.17) will load fine only >>>> after >>>> I created the following rules in the deliverance.xml file: >>>> >>>> <proxy path="contains: emptypage" class="emptypage"> >>>> <dest href="http://127.0.0.1:8080/" /> >>>> </proxy> >>>> <rule class="emptypage"> >>>> <replace content="element:/html/head" >>>> theme="element:/html/head" /> >> >> <replace >>>> >>>> content="element:/html/body" theme="element:/html/body" /> >>>> >>>> </rule> >>>> >>>> This rule was necessary because the hint in emptypage.pt (<meta >>>> http-equiv="x-deliverance-no-theme" content="1">) doesn't seem to >>>> prevent >>>> Deliverance from applying the theme. >>>> >>>> When switching into Plone's edit mode, Kupu loads fine and all the >>>> controls and windows load and populate with all the existing data. >>>> Edits >>>> can be made on screen and the Submit button sends a POST back to Apache, >>>> but the response >>>> >>>> I can bypass the Apache and hit Deliverance directly. Still, Kupu loads >>>> fine but saves don't commit. >>>> >>>> I wonder if the order of elements in the head are being reorganized in a >>>> way that is incompatible with Kupu. >>>> >>>> Any ideas would be appreciated. >>>> >>>> Thanks, >>>> Don Fick >>>> don@... >>>> >>>> >>>> -- >>>> Archive: >>>> >>>> >>>> http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/06/1246327237306 >> >> To >>>> >>>> unsubscribe send an email with subject "unsubscribe" to >>>> deliverance-devel@.... Please contact >>>> deliverance-devel-manager@... for questions. >>>> >>>> >>> >>> >>> >> >> >> >> -- >> Archive: >> http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246475576932 >> To unsubscribe send an email with subject "unsubscribe" to >> deliverance-devel@.... Please contact >> deliverance-devel-manager@... for questions. >> > > > > -- > Archive: > http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246544869144 > To unsubscribe send an email with subject "unsubscribe" to > deliverance-devel@.... Please contact > deliverance-devel-manager@... for questions. > > -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
-
Oddly enough the headers look pretty similar between firebug <-> deliverance and firebug <-> Plone. However when I changed my form action to GET, it worked fine. There has to be an error somewhere in the underlying subtleties of proxying a POST request -- either in the deliverance proxy itself, or in the PasteWSGI server. I don't even know where to begin with PasteWSGI and I've only begun looking at the deliverance code, so I'm not yet sure how much of the actual proxying mechanics is handled by deliverance. As a side note, I think the "date" header is malformed from PasteWSGI. I'm getting back "Date: Thu, 02 Jul 2009 17:32:10 GMT, Thu, 02 Jul 2009 17:32:10 GMT" in my header. The deliverance header log shows up correctly, so I think PasteWSGI it appending its own date to the existing header. On Thu, Jul 2, 2009 at 11:08 AM, Ian Bicking <ianb@...> wrote: > If you want to see exactly what Deliverance sends to Zope, use > --debug-headers. Use --debug-headers --debug-headers to show the > bodies of the requests. It shows these on the console. > > You can match this up against LiveHTTPHeaders or what Firebug shows > when you connect directly to Zope. This might reveal something. > > On Thu, Jul 2, 2009 at 9:27 AM, Don Fick<don@...> wrote: > > @Ian: A good tip but rewrite links is definitely not present. > > > > @Matt: Likewise I see some of the same problems when trying to use > > plone_control_panel functions through Deliverance, such as > > /@@site-controlpanel. > > > > I setup a completely fresh install of Plone 3.17 (default theme) and a > very > > simple Deliverance rules file. > > > > The key parts of the Deliverance rule file are" > > <proxy path="/"> > > <dest > > href=" > http://127.0.0.1:8080/VirtualHostBase/http/donfick.com:8085/deltest/VirtualHostRoot > " > > /> > > </proxy> > > <rule suppress-standard="1"> > > <replace content="element:/html/head" > > theme="element:/html/head" /> > > <replace content="element:/html/body" > > theme="element:/html/body" /> > > </rule> > > > > So there is no <response rewrite-links="1" /> > > > > The pages server out of Plone and through Deliverance with no problem. > Both > > sites look exactly the same. Kupu loads without a problem. I have done > diff > > comparisons and the only difference between the HTML "direct-from-Plone" > and > > "through-Deliverance" is the hostname paths in the href attributes due to > > virtual host monster. > > > > When a full page Kupu POST goes straight to Plone, the server responds > with > > a 302 and the browser loads the redirect without a problem and the > changes > > are saved. > > When a full page Kupu POST goes to Deliverance, the Plone server responds > > with a 200 and the content contains a full HTML page. The HTML is the > full, > > original edit page HTML without the edits. Zope log file snippets appear > > below. > > > > This problem doesn't affect all POSTs. The Plone commenting function > works > > without a problem. > > > > Is there an option to increase the logging level in Zope/Plone? Nothing > > related to this appears in the instance.log and nothing appears in the > ZMI > > error_log. > > > > Thanks, > > Don > > > > ---------------------- > > Standard Plone > > > > This is a successful edit with content stored in Plone: > > Zope instance-Z2.log following a POST directly to Plone. The server > responds > > with a 302 and the browser loads the redirect without a problem and the > > changes are saved. > > 74.183.224.6 - Anonymous [02/Jul/2009:13:08:53 +0000] "POST > > /deltest/front-page/atct_edit HTTP/1.1" 302 389 > > "http://slice1.donfick.com:8080/deltest/front-page/edit" "Mozilla/5.0 > > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > > Firefox/3.0.11" > > 74.183.224.6 - Anonymous [02/Jul/2009:13:08:53 +0000] "GET > > /deltest/front-page/@@plone_lock_operations/safe_unlock HTTP/1.1" 204 144 > > "http://slice1.donfick.com:8080/deltest/front-page/edit" "Mozilla/5.0 > > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > > Firefox/3.0.11" > > 74.183.224.6 - Anonymous [02/Jul/2009:13:08:53 +0000] "GET > > /deltest/front-page HTTP/1.1" 200 35985 > > "http://slice1.donfick.com:8080/deltest/front-page/edit" "Mozilla/5.0 > > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > > Firefox/3.0.11" > > > > POST reponse header > > (Status-Line) HTTP/1.1 302 Moved Temporarily > > Server Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 > > Plone/3.1.7 > > Date Thu, 02 Jul 2009 13:53:11 GMT > > Content-Length 42 > > Content-Type text/plain; charset=utf-8 > > Location http://donfick.com:8080/deltest/front-page > > Set-Cookie statusmessages="AcRDaGFuZ2VzIHNhdmVkLmluZm8="; Path=/ > > > > --------------------------- > > With Deliverance in Front > > > > This is a failed edit: > > Zope instance-Z2.log following a POST through Deliverance. The server > > responds with a 200 where the content is HTML > > 127.0.0.1 - Anonymous [02/Jul/2009:13:01:52 +0000] "POST > > /VirtualHostBase/http/ > donfick.com:8085/deltest/VirtualHostRoot/front-page/atct_edit > > HTTP/1.1" 200 79486 "http://donfick.com:8085/front-page/edit" > "Mozilla/5.0 > > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > > Firefox/3.0.11" > > 127.0.0.1 - Anonymous [02/Jul/2009:13:01:52 +0000] "GET > > /VirtualHostBase/http/ > donfick.com:8085/deltest/VirtualHostRoot/front-page/@@plone_lock_operations/safe_unlock > > HTTP/1.1" 204 144 "http://donfick.com:8085/front-page/edit" "Mozilla/5.0 > > (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 > > Firefox/3.0.11" > > > > POST reponse header > > (Status-Line) HTTP/1.0 200 OK > > Server PasteWSGIServer/0.5 Python/2.5.2, Zope/(Zope 2.10.6-final, python > > 2.4.5, linux2) ZServer/1.1 Plone/3.1.7 > > Date Thu, 02 Jul 2009 13:53:47 GMT, Thu, 02 Jul 2009 13:53:47 GMT > > Expires Sat, 1 Jan 2000 00:00:00 GMT > > Content-Type text/html;charset=utf-8 > > Content-Language en-us > > Content-Length 79345 > > > > > > Don Fick > > don@... > > > > > > > > On Jul 1, 2009, at 3:12 PM, Matt Perry wrote: > > > >> I actually have the same problem with a PloneFormGen-generated form. > I'm > >> applying no themeing right now and have link rewriting on, but pressing > >> the > >> "submit" button results in a POST showing up in my Zope access log, and > >> getting ignored. The form works fine from the native Plone interface or > >> through an Apache proxy, however. > >> > >> On Jul 01, 2009 12:27 PM, Ian Bicking wrote: > >>> > >>> One problem people have had with Kupu is that it looks for the > >>> Zope-specific use of a <base> tag to identify the location of the > >>> object (instead of location.href or something). If you configure > >>> Deliverance to rewrite links (<response rewrite-links="1" /> then it > >>> will eliminate the <base> tag. I think people have gotten it to work > >>> just by adjusting that configuration. > >>> > >>> > >>> On Mon, Jun 29, 2009 at 9:00 PM, Don Fick<don@...> wrote: > >>>> > >>>> I have Deliverance running on top of the standard Plone theme. > (actually > >>>> the Plone Tableless theme). > >>>> > >>>> The complete setup looks like this > >>>> > >>>> Apache in front with mod_deflate to do HTTP Compression > >>>> Deliverance doing the themeing voodoo that it do > >>>> Plone 3.17 > >>>> > >>>> Everything seems to work reasonably well except Kupu. > >>>> > >>>> Kupu (stock version that ships with Plone 3.17) will load fine only > >>>> after > >>>> I created the following rules in the deliverance.xml file: > >>>> > >>>> <proxy path="contains: emptypage" class="emptypage"> > >>>> <dest href="http://127.0.0.1:8080/" /> > >>>> </proxy> > >>>> <rule class="emptypage"> > >>>> <replace content="element:/html/head" > >>>> theme="element:/html/head" /> > >> > >> <replace > >>>> > >>>> content="element:/html/body" theme="element:/html/body" /> > >>>> > >>>> </rule> > >>>> > >>>> This rule was necessary because the hint in emptypage.pt (<meta > >>>> http-equiv="x-deliverance-no-theme" content="1">) doesn't seem to > >>>> prevent > >>>> Deliverance from applying the theme. > >>>> > >>>> When switching into Plone's edit mode, Kupu loads fine and all the > >>>> controls and windows load and populate with all the existing data. > >>>> Edits > >>>> can be made on screen and the Submit button sends a POST back to > Apache, > >>>> but the response > >>>> > >>>> I can bypass the Apache and hit Deliverance directly. Still, Kupu > loads > >>>> fine but saves don't commit. > >>>> > >>>> I wonder if the order of elements in the head are being reorganized in > a > >>>> way that is incompatible with Kupu. > >>>> > >>>> Any ideas would be appreciated. > >>>> > >>>> Thanks, > >>>> Don Fick > >>>> don@... > >>>> > >>>> > >>>> -- > >>>> Archive: > >>>> > >>>> > >>>> > http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/06/1246327237306 > >> > >> To > >>>> > >>>> unsubscribe send an email with subject "unsubscribe" to > >>>> deliverance-devel@.... Please contact > >>>> deliverance-devel-manager@... for questions. > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Archive: > >> > http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246475576932 > >> To unsubscribe send an email with subject "unsubscribe" to > >> deliverance-devel@.... Please contact > >> deliverance-devel-manager@... for questions. > >> > > > > > > > > -- > > Archive: > > > http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246544869144 > > To unsubscribe send an email with subject "unsubscribe" to > > deliverance-devel@.... Please contact > > deliverance-devel-manager@... for questions. > > > > > > > > -- > Ian Bicking | http://blog.ianbicking.org | > http://topplabs.org/civichacker > > > -- > Archive: > http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246547329816 > To unsubscribe send an email with subject "unsubscribe" to > deliverance-devel@.... Please contact > deliverance-devel-manager@... for questions. > >
-
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Perry wrote: > Oddly enough the headers look pretty similar between firebug <-> deliverance > and firebug <-> Plone. > > However when I changed my form action to GET, it worked fine. There has to > be an error somewhere in the underlying subtleties of proxying a POST > request -- either in the deliverance proxy itself, or in the PasteWSGI > server. I don't even know where to begin with PasteWSGI and I've only begun > looking at the deliverance code, so I'm not yet sure how much of the actual > proxying mechanics is handled by deliverance. There was a bug in Paste 1.6 which failed to forward the 'Content-Length' header to the origin server: http://trac.pythonpaste.org/pythonpaste/ticket/273 which caused POSTs to fail. I don't know if that is relevant to your case. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@... Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKTQVJ+gerLs4ltQ4RAqMUAKCWeLU55o/eKns/Lk7yJ7QlzYYqJwCdHpSL YU5CpEYlqj51NODZ6c3AIXw= =nfqW -----END PGP SIGNATURE-----
-
Thanks for the tip! I ran tcpdump on port 8080 (Zope server) and it seems that the content-type header is missing in the POST request when accessed through the deliverance proxy. This probably doesn't matter so much for the regular forms on the Plone site, but PloneFormGen and Kupu forms have enctype="multipart/form-data" which is being ignored. On Thu, Jul 2, 2009 at 3:06 PM, Tres Seaver <tseaver@...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matt Perry wrote: > > Oddly enough the headers look pretty similar between firebug <-> > deliverance > > and firebug <-> Plone. > > > > However when I changed my form action to GET, it worked fine. There has > to > > be an error somewhere in the underlying subtleties of proxying a POST > > request -- either in the deliverance proxy itself, or in the PasteWSGI > > server. I don't even know where to begin with PasteWSGI and I've only > begun > > looking at the deliverance code, so I'm not yet sure how much of the > actual > > proxying mechanics is handled by deliverance. > > There was a bug in Paste 1.6 which failed to forward the > 'Content-Length' header to the origin server: > > http://trac.pythonpaste.org/pythonpaste/ticket/273 > > which caused POSTs to fail. I don't know if that is relevant to your case. > > > Tres. > - -- > =================================================================== > Tres Seaver +1 540-429-0999 tseaver@... > Palladion Software "Excellence by Design" http://palladion.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFKTQVJ+gerLs4ltQ4RAqMUAKCWeLU55o/eKns/Lk7yJ7QlzYYqJwCdHpSL > YU5CpEYlqj51NODZ6c3AIXw= > =nfqW > -----END PGP SIGNATURE----- > > > -- > Archive: > http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246561637346 > To unsubscribe send an email with subject "unsubscribe" to > deliverance-devel@.... Please contact > deliverance-devel-manager@... for questions. > >
-
Ok, I tracked down the bug. It's in WSGIProxy's exactproxy.py, so it's technically not a deliverance issue. If you're in a virtualenv you can edit ./lib/python2.5/site-packages/WSGIProxy-0.1-py2.5.egg/wsgiproxy/exactproxy.py and make the following change: 79,80c79,80 < if environ.get('Content-Type'): < headers['Content-Type'] = environ['Content-Type'] --- > if environ.get('CONTENT_TYPE'): > headers['Content-Type'] = environ['CONTENT_TYPE'] Then restart the deliverance proxy. I have Kupu forms and my PloneFormGen form working now. I'll submit a proper ticket and patch to WSGIProxy. - Matt On Thu, Jul 2, 2009 at 8:12 PM, Matt Perry <matt@...> wrote: > Thanks for the tip! I ran tcpdump on port 8080 (Zope server) and it seems > that the content-type header is missing in the POST request when accessed > through the deliverance proxy. > > This probably doesn't matter so much for the regular forms on the Plone > site, but PloneFormGen and Kupu forms have enctype="multipart/form-data" > which is being ignored. > > > > > > On Thu, Jul 2, 2009 at 3:06 PM, Tres Seaver <tseaver@...> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Matt Perry wrote: >> > Oddly enough the headers look pretty similar between firebug <-> >> deliverance >> > and firebug <-> Plone. >> > >> > However when I changed my form action to GET, it worked fine. There has >> to >> > be an error somewhere in the underlying subtleties of proxying a POST >> > request -- either in the deliverance proxy itself, or in the PasteWSGI >> > server. I don't even know where to begin with PasteWSGI and I've only >> begun >> > looking at the deliverance code, so I'm not yet sure how much of the >> actual >> > proxying mechanics is handled by deliverance. >> >> There was a bug in Paste 1.6 which failed to forward the >> 'Content-Length' header to the origin server: >> >> http://trac.pythonpaste.org/pythonpaste/ticket/273 >> >> which caused POSTs to fail. I don't know if that is relevant to your >> case. >> >> >> Tres. >> - -- >> =================================================================== >> Tres Seaver +1 540-429-0999 tseaver@... >> Palladion Software "Excellence by Design" http://palladion.com >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFKTQVJ+gerLs4ltQ4RAqMUAKCWeLU55o/eKns/Lk7yJ7QlzYYqJwCdHpSL >> YU5CpEYlqj51NODZ6c3AIXw= >> =nfqW >> -----END PGP SIGNATURE----- >> >> >> -- >> Archive: >> http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246561637346 >> To unsubscribe send an email with subject "unsubscribe" to >> deliverance-devel@.... Please contact >> deliverance-devel-manager@... for questions. >> >> >-
I checked out svn and the fix is already there, funny enough: http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2008/12/1229598411425/forum_view Don, If you update your WSGIProxy to the trunk version and copy it into your site-packages directory, you should be all set with Kupu. - Matt On Thu, Jul 2, 2009 at 9:13 PM, Matt Perry <matt@...> wrote: > Ok, I tracked down the bug. It's in WSGIProxy's exactproxy.py, so it's > technically not a deliverance issue. > > If you're in a virtualenv you can edit > ./lib/python2.5/site-packages/WSGIProxy-0.1-py2.5.egg/wsgiproxy/exactproxy.py > and make the following change: > > 79,80c79,80 > < if environ.get('Content-Type'): > < headers['Content-Type'] = environ['Content-Type'] > --- > > if environ.get('CONTENT_TYPE'): > > headers['Content-Type'] = environ['CONTENT_TYPE'] > > Then restart the deliverance proxy. I have Kupu forms and my PloneFormGen > form working now. > > I'll submit a proper ticket and patch to WSGIProxy. > > > - Matt > > > > > On Thu, Jul 2, 2009 at 8:12 PM, Matt Perry <matt@...> wrote: > >> Thanks for the tip! I ran tcpdump on port 8080 (Zope server) and it seems >> that the content-type header is missing in the POST request when accessed >> through the deliverance proxy. >> >> This probably doesn't matter so much for the regular forms on the Plone >> site, but PloneFormGen and Kupu forms have enctype="multipart/form-data" >> which is being ignored. >> >> >> >> >> >> On Thu, Jul 2, 2009 at 3:06 PM, Tres Seaver <tseaver@...>wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Matt Perry wrote: >>> > Oddly enough the headers look pretty similar between firebug <-> >>> deliverance >>> > and firebug <-> Plone. >>> > >>> > However when I changed my form action to GET, it worked fine. There >>> has to >>> > be an error somewhere in the underlying subtleties of proxying a POST >>> > request -- either in the deliverance proxy itself, or in the PasteWSGI >>> > server. I don't even know where to begin with PasteWSGI and I've only >>> begun >>> > looking at the deliverance code, so I'm not yet sure how much of the >>> actual >>> > proxying mechanics is handled by deliverance. >>> >>> There was a bug in Paste 1.6 which failed to forward the >>> 'Content-Length' header to the origin server: >>> >>> http://trac.pythonpaste.org/pythonpaste/ticket/273 >>> >>> which caused POSTs to fail. I don't know if that is relevant to your >>> case. >>> >>> >>> Tres. >>> - -- >>> =================================================================== >>> Tres Seaver +1 540-429-0999 tseaver@... >>> Palladion Software "Excellence by Design" http://palladion.com >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.6 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iD8DBQFKTQVJ+gerLs4ltQ4RAqMUAKCWeLU55o/eKns/Lk7yJ7QlzYYqJwCdHpSL >>> YU5CpEYlqj51NODZ6c3AIXw= >>> =nfqW >>> -----END PGP SIGNATURE----- >>> >>> >>> -- >>> Archive: >>> http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246561637346 >>> To unsubscribe send an email with subject "unsubscribe" to >>> deliverance-devel@.... Please contact >>> deliverance-devel-manager@... for questions. >>> >>> >> >
-
Thanks Matt. I dropped in the updated exactproxy.py and I can confirm that the problem with Kupu editing and other multipart form posts seems to be fixed. I'm not sure which/where is the authoritative WSGIProxy svn repository. I ended up pulling from Webware for Python (http://svn.w4py.org/Paste/WSGIProxy/trunk ) Can anyone confirm that this is the best place to get this update? Thanks, Don Don Fick don@... On Jul 2, 2009, at 9:21 PM, Matt Perry wrote: > I checked out svn and the fix is already there, funny enough: http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2008/12/1229598411425/forum_view > > Don, If you update your WSGIProxy to the trunk version and copy it > into your site-packages directory, you should be all set with Kupu. > > - Matt > > > On Thu, Jul 2, 2009 at 9:13 PM, Matt Perry <matt@...> wrote: > Ok, I tracked down the bug. It's in WSGIProxy's exactproxy.py, so > it's technically not a deliverance issue. > > If you're in a virtualenv you can edit ./lib/python2.5/site-packages/ > WSGIProxy-0.1-py2.5.egg/wsgiproxy/exactproxy.py and make the > following change: > > 79,80c79,80 > < if environ.get('Content-Type'): > < headers['Content-Type'] = environ['Content-Type'] > --- > > if environ.get('CONTENT_TYPE'): > > headers['Content-Type'] = environ['CONTENT_TYPE'] > > Then restart the deliverance proxy. I have Kupu forms and my > PloneFormGen form working now. > > I'll submit a proper ticket and patch to WSGIProxy. > > > - Matt > > > > > On Thu, Jul 2, 2009 at 8:12 PM, Matt Perry <matt@...> wrote: > Thanks for the tip! I ran tcpdump on port 8080 (Zope server) and it > seems that the content-type header is missing in the POST request > when accessed through the deliverance proxy. > > This probably doesn't matter so much for the regular forms on the > Plone site, but PloneFormGen and Kupu forms have enctype="multipart/ > form-data" which is being ignored. > > > > > > On Thu, Jul 2, 2009 at 3:06 PM, Tres Seaver <tseaver@...> > wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matt Perry wrote: > > Oddly enough the headers look pretty similar between firebug <-> > deliverance > > and firebug <-> Plone. > > > > However when I changed my form action to GET, it worked fine. > There has to > > be an error somewhere in the underlying subtleties of proxying a > POST > > request -- either in the deliverance proxy itself, or in the > PasteWSGI > > server. I don't even know where to begin with PasteWSGI and I've > only begun > > looking at the deliverance code, so I'm not yet sure how much of > the actual > > proxying mechanics is handled by deliverance. > > There was a bug in Paste 1.6 which failed to forward the > 'Content-Length' header to the origin server: > > http://trac.pythonpaste.org/pythonpaste/ticket/273 > > which caused POSTs to fail. I don't know if that is relevant to > your case. > > > Tres. > - -- > =================================================================== > Tres Seaver +1 540-429-0999 tseaver@... > Palladion Software "Excellence by Design" http://palladion.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFKTQVJ+gerLs4ltQ4RAqMUAKCWeLU55o/eKns/Lk7yJ7QlzYYqJwCdHpSL > YU5CpEYlqj51NODZ6c3AIXw= > =nfqW > -----END PGP SIGNATURE----- > > > -- > Archive: http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246561637346 > To unsubscribe send an email with subject "unsubscribe" to deliverance-devel@... > . Please contact deliverance-devel-manager@... for > questions. > > > > > > > -- > Archive: http://www.coactivate.org/[…]/1246584088044 > To unsubscribe send an email with subject "unsubscribe" to deliverance-devel@... > . Please contact deliverance-devel-manager@... for > questions.
-
Hi, On Fri, Jul 3, 2009 at 2:14 PM, Don Fick<don@...> wrote: > Thanks Matt. I dropped in the updated exactproxy.py and I can confirm that > the problem with Kupu editing and other multipart form posts seems to be > fixed. > I'm not sure which/where is the authoritative WSGIProxy svn repository. I > ended up pulling from Webware for Python > (http://svn.w4py.org/Paste/WSGIProxy/trunk) Can anyone confirm that this is > the best place to get this update? I guess http://svn.pythonpaste.org/Paste/WSGIProxy/trunk/ is the official repository -- Gael > Thanks, > Don > Don Fick > don@... > > > On Jul 2, 2009, at 9:21 PM, Matt Perry wrote: > > I checked out svn and the fix is already there, funny enough: > http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2008/12/1229598411425/forum_view > > Don, If you update your WSGIProxy to the trunk version and copy it into your > site-packages directory, you should be all set with Kupu. > > - Matt > > > On Thu, Jul 2, 2009 at 9:13 PM, Matt Perry <matt@...> wrote: >> >> Ok, I tracked down the bug. It's in WSGIProxy's exactproxy.py, so it's >> technically not a deliverance issue. >> >> If you're in a virtualenv you can edit >> ./lib/python2.5/site-packages/WSGIProxy-0.1-py2.5.egg/wsgiproxy/exactproxy.py >> and make the following change: >> >> 79,80c79,80 >> < if environ.get('Content-Type'): >> < headers['Content-Type'] = environ['Content-Type'] >> --- >> > if environ.get('CONTENT_TYPE'): >> > headers['Content-Type'] = environ['CONTENT_TYPE'] >> >> Then restart the deliverance proxy. I have Kupu forms and my PloneFormGen >> form working now. >> >> I'll submit a proper ticket and patch to WSGIProxy. >> >> >> - Matt >> >> >> >> On Thu, Jul 2, 2009 at 8:12 PM, Matt Perry <matt@...> wrote: >>> >>> Thanks for the tip! I ran tcpdump on port 8080 (Zope server) and it >>> seems that the content-type header is missing in the POST request when >>> accessed through the deliverance proxy. >>> >>> This probably doesn't matter so much for the regular forms on the Plone >>> site, but PloneFormGen and Kupu forms have enctype="multipart/form-data" >>> which is being ignored. >>> >>> >>> >>> >>> On Thu, Jul 2, 2009 at 3:06 PM, Tres Seaver <tseaver@...> >>> wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Matt Perry wrote: >>>> > Oddly enough the headers look pretty similar between firebug <-> >>>> > deliverance >>>> > and firebug <-> Plone. >>>> > >>>> > However when I changed my form action to GET, it worked fine. There >>>> > has to >>>> > be an error somewhere in the underlying subtleties of proxying a POST >>>> > request -- either in the deliverance proxy itself, or in the PasteWSGI >>>> > server. I don't even know where to begin with PasteWSGI and I've only >>>> > begun >>>> > looking at the deliverance code, so I'm not yet sure how much of the >>>> > actual >>>> > proxying mechanics is handled by deliverance. >>>> >>>> There was a bug in Paste 1.6 which failed to forward the >>>> 'Content-Length' header to the origin server: >>>> >>>> http://trac.pythonpaste.org/pythonpaste/ticket/273 >>>> >>>> which caused POSTs to fail. I don't know if that is relevant to your >>>> case. >>>> >>>> >>>> Tres. >>>> - -- >>>> =================================================================== >>>> Tres Seaver +1 540-429-0999 tseaver@... >>>> Palladion Software "Excellence by Design" http://palladion.com >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.6 (GNU/Linux) >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>>> >>>> iD8DBQFKTQVJ+gerLs4ltQ4RAqMUAKCWeLU55o/eKns/Lk7yJ7QlzYYqJwCdHpSL >>>> YU5CpEYlqj51NODZ6c3AIXw= >>>> =nfqW >>>> -----END PGP SIGNATURE----- >>>> >>>> >>>> -- >>>> Archive: >>>> http://www.coactivate.org/projects/deliverance/lists/deliverance-discussion/archive/2009/07/1246561637346 >>>> To unsubscribe send an email with subject "unsubscribe" to >>>> deliverance-devel@.... Please contact >>>> deliverance-devel-manager@... for questions. >>>> >>> >> > > > > -- > Archive: http://www.coactivate.org/[…]/1246584088044 > To unsubscribe send an email with subject "unsubscribe" to > deliverance-devel@.... Please contact > deliverance-devel-manager@... for questions. > > > > -- > Archive: http://www.coactivate.org/[…]/1246623295637 > To unsubscribe send an email with subject "unsubscribe" to > deliverance-devel@.... Please contact > deliverance-devel-manager@... for questions. >
-
-
-
-
-
-
-
-
-
-
-
Deliverance Discussion
text.html (text/html) 15.2 kB