[Dachs-support] UWS and user access control
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Tue May 3 11:41:40 CEST 2016
Hi Ivan,
On Mon, May 02, 2016 at 09:20:28PM +0200, Ivan Zolotukhin wrote:
> On Mon, May 2, 2016 at 8:34 PM, Markus Demleitner
> <msdemlei at ari.uni-heidelberg.de> wrote:
> For queries to incorrect job URL:
>
> 2016-05-02 21:08:12+0200 [-] >>>>>>>>>>>>>>> _RIJl3
> 2016-05-02 21:08:12+0200 [-] *X*X* 'Service' object has no attribute
> 'uws' (see info for traceback)
> 2016-05-02 21:08:12+0200 [-] "10.10.135.118" - - [02/May/2016:19:08:11
> +0000] "HEAD /res/service1/r/uws.xml/_RIJl3 HTTP/1.1" 400 - "-"
> "curl/7.29.0"
Jup -- that's a classic why unit tests shouldn't share resources: my
tests didn't catch the underlying bug because they used "warm"
objects.
The other bug, the bad redirect, similarly was caused by the HTTP
interface which the unit tests weren't exercising.
Sorry for abusing you as a tester -- I simply don't have any current
application for this kind of thing.
Fixes are in at svn rev. 5027.
>
> For queries to correct job URL:
>
> 2016-05-02 21:09:52+0200 [-] >>>>>>>>>>>>>>> _RIJl3
> 2016-05-02 21:09:52+0200 [-] *X*X* This resource cannot respond to the
> HTTP 'HEAD' method (see info for traceback)
> 2016-05-02 21:09:52+0200 [-] "10.120.0.14" - - [02/May/2016:19:09:51
> +0000] "HEAD /res/service2/r/uws.xml/_RIJl3 HTTP/1.1" 400 - "-"
> "curl/7.29.0"
That's a bit different: Don't use the HTTP HEAD method on DaCHS in
general (which will definitely not do the right thing) and in
particular not on the UWS part -- UWS keeps apart the HTTP methods
(POST, GET, HEAD, DELETE, etc) fairly strictly, and so DaCHS refuses
to accept requests with methods it doesn't understand. This includes
HEAD.
So, just use GET and things are fine.
Cheers,
Markus
More information about the Dachs-support
mailing list