[silva-dev] extended HTTP method support in 2.3

[Sylvain Viollon]

On Wed, 27 Apr 2011 11:09:42 -0500
Andy Altepeter <aaltepet at altepeter.net> wrote:

> Greetings Devs,
> 

  Hello,


  I will have a more complete response after, as I need to do some
  testing.

> Our current production environment is Silva 2.1.  We have a lot built
> on top of Silva.  We found in the zope error logs that for our various
> browser views attached to Silva Objects (e.g. those accessed via
> @@somename.html), we saw a number of errors for PROPFIND and OPTIONS
> requests.  It turns out that Five views did not handle these HTTP
> methods.  (they didn't handle HEAD, either).
> 
> Infrae added a hack to support HEAD in Products.SilvaLayout (using
> MyRolesProxy).  MyRolesProxy essentially tells the object the view is
> on to handle the requested http method.We've employed the same
> approach for PROPFIND and OPTIONS.
> 
> Silva 2.3 is a huge restructing.  In particular, silva.core.views and
> silva.core.layout were added.  silva.core.views.views.SilvaPage DOES
> support the HEAD method.
> 

  We don't really use anymore the hacked and never quite worked Five
  views.

> However, it does not support OPTIONS and PROPFIND.  Not only are they
> not supported, Silva does not fail gracefully.  (see attached telnet
> session for doing an OPTIONS on /silva/index.html).
> 

  Those are not implemented. I will see if it needed and what they
  should do. Since they are not implemented, I guess this fallback to
  the never quite worked Zope 2 WebDAV support try-o-clever-but-failed
  to distinguish a web browser from a webdav request.


> I'd like to see support for OPTIONS and PROPFIND (at least), or some
> means of proxying all http methods not handled by the SilvaPage to the
> context itself.  Silva isn't in control of what clients request, and
> _should_ fail gracefully if it refuses to handle standard http methods
> on SilvaPages.
> 
> On a related note, there seems to be some issue with the OPTIONS
> request to a Silva object.  I think this is in infrae.wsgi.  Here's a
> telnet session:

  It is just that that the OPTIONS query doesn't return a string.
  Probably None. That is not supported in WSGI (all return values must
  be string).

  But I will have a look in detail.

  Regards,

  Sylvain,

-- 
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands