new adding view and HEAD requests

--===============8314145739532414179==
Content-Type: multipart/alternative; boundary=20cf300fb307670bce04aadf2dae

--20cf300fb307670bce04aadf2dae
Content-Type: text/plain; charset=ISO-8859-1

Hey Devs,

This may seem like an odd issue, but it caused our webserver to crash.
 hard.  We have two silva environments, one for Silva 2.3 and one for Silva
2.1 (where our legacy content resides).  Our frontend apache webserver has a
perl module which issues HEAD requests to each backend Silva in order to
determine which backend to serve the content from.

Today we had an issue where a url to one of our public domains was causing
the frontend server to crash.  Post-mortem analysis revealed that HEAD
requests to the Silva 2.3 adding view raise a redirect to the GET of the
adding view.  We've worked around this problem, but I wanted to bring it up
to this gruop.

Try this (Silva 2.3 of course):

1) create a new silva root, at '/silva/'
2) open telnet 8080
3) enter the following
HEAD /silva/edit/+ HTTP/1.1
HOST: localhost:8080
4) Silva's response will be a 302 redirect with a location header of '
http://localhost:8080/silva/edit/+'

Shouldn't a head request to a view like this (which will display a web page)
return a valid 200 response, or perhaps since it requires authorization
beyond what 'Anonymous' has, initiate that instead?

The code in question is this:
silva.core.smi.edit.container.AddingView.publishTraverse

This request is actually seen by zope as the following path:
/silva/edit/+/HEAD
I'm not sure how to correct this, but I think that publishTraverse should
look for the HEAD method and return it instead.  I would expect GET requests
to get stuck in the same spot, so I am not sure why they work.

Thoughts?
Andy

--20cf300fb307670bce04aadf2dae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Devs,<div><br></div><div>This may seem like an odd issue, but it caused=
 our webserver to crash. =A0hard. =A0We have two silva environments, one fo=
r Silva 2.3 and one for Silva 2.1 (where our legacy content resides). =A0Ou=
r frontend apache webserver has a perl module which issues HEAD requests to=
 each backend Silva in order to determine which backend to serve the conten=
t from.</div>
<div><br></div><div>Today we had an issue where a url to one of our public =
domains was causing the frontend server to crash. =A0Post-mortem analysis r=
evealed that HEAD requests to the Silva 2.3 adding view raise a redirect to=
 the GET of the adding view. =A0We&#39;ve worked around this problem, but I=
 wanted to bring it up to this gruop.</div>
<div><br></div><div>Try this (Silva 2.3 of course):</div><div><br></div><di=
v>1) create a new silva root, at &#39;/silva/&#39;</div><div>2) open telnet=
 8080</div><div>3) enter the following</div><div>HEAD /silva/edit/+ HTTP/1.=
1</div>
<div>HOST: localhost:8080</div><div>4) Silva&#39;s response will be a 302 r=
edirect with a location header of &#39;<a href=3D"http://localhost:8080/sil=
va/edit/+">http://localhost:8080/silva/edit/+</a>&#39;</div><div><br></div>
<div>Shouldn&#39;t a head request to a view like this (which will display a=
 web page) return a valid 200 response, or perhaps since it requires author=
ization beyond what &#39;Anonymous&#39; has, initiate that instead?</div>
<div><br></div><div>The code in question is this:</div><div>silva.core.smi.=
edit.container.AddingView.publishTraverse</div><div><br></div><div>This req=
uest is actually seen by zope as the following path:</div><div>/silva/edit/=
+/HEAD</div>
<div>I&#39;m not sure how to correct this, but I think that publishTraverse=
 should look for the HEAD method and return it instead. =A0I would expect G=
ET requests to get stuck in the same spot, so I am not sure why they work.<=
/div>
<div><br></div><div>Thoughts?</div><div>Andy</div><div><br></div>

--20cf300fb307670bce04aadf2dae--

--===============8314145739532414179==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
silva-dev mailing list
silva-dev-IAPFreCvJWM6s/[email protected]
https://lists.infrae.com/mailman/listinfo/silva-dev

--===============8314145739532414179==--