RE: Summary of If header eval tests

Hi,

another update...:

1) "forcing" IIS to use strong etags (by obtaining the etag delayed after
the PUT) does not fix the IIS issue.

2) I've also added a few test cases that test putting the etag into the
"If-Match" header rather than the If header, such as

	if: (<opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:20681>)
(Not<DAV:no-lock>)
	if-match: "110969"

rather than:

	if: (<opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:20681>
["110969"]) (Not<DAV:no-lock> ["110969"])

This should be equivalent but fails in Apache/moddav ([1]).

So contrary to what we believed, protecting conditional PUTs using strong
etags currently does not interoperate well at all.

How do we move forward on this issue?

Julian


[1] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16593>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
> Sent: Wednesday, January 29, 2003 7:37 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: Summary of If header eval tests
>
>
>
> Hi,
>
> two updates regarding the situation on Apache/moddav:
>
> Issue 1b) has been fixed (not tested yet).
>
> Issue 1a) is a bit more complicated. The problem here is that my test case
> was obtaining it's entity tags from PUT operations. Apache/moddav (when
> using the filesystem backend) returns weak entity tags which turn into
> strong tags once a certain time has elapsed. Rearranging the code to wait
> after the PUT and only then retrieve the etag using HEAD indeed provides
> strong etags, and the test failures disappear. So the issue here
> really has
> nothing to do with the If header evaluation.
>
> The issue with IIS may indeed be related -- I'll have to check that
> tomorrow.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
> > Sent: Monday, January 27, 2003 3:58 PM
> > To: w3c-dist-auth@w3c.org
> > Subject: Summary of If header eval tests
> >
> >
> > Hi,
> >
> > during the WG meeting I volunteered to do some tests with the If header
> > syntax that Geoff, Stefan and myself have been proposing to do
> conditional
> > PUTs (where both a lock-token and an entity tag is known, and
> the request
> > should succeed if the etag still matches, and the lock-token
> > either matches
> > or the lock is gone).
> >
> > A possible syntax for this is:
> >
> > (<opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:17289> ["89657"])
> > (Not<DAV:no-lock> ["89657"])
> >
> > where:
> >
> > opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:17289 is a valid
> > lock-token,
> > DAV:no-lock is a known-to-be-invalid lock token and
> > "89657" is the etag obtained from the previous PUT.
> >
> >
> > Here are the test results:
> >
> > 1) Moddav in Apache 2.0.44
> >
> > Found (and reported) two bugs:
> >
> > a) etags in If header validation do not seem to work [1]
> > b) lock tokens are only accepted in the specific syntax that moddav
> > internally uses [2]
> >
> >
> > 2) IIS 5.0
> >
> > Identified bug similar to [1]. Does anybody know how to report
> bugs in IIS
> > with an actual chance that they get fixed? (:-)
> >
> >
> > 3) SAP Enterprise Portal
> >
> > Tests pass (admittingly after we fixed to bugs in the If header
> > validation).
> >
> >
> > The tests are written in JScript and require MSXML and the
> > Windows Scripting
> > Host (zip file attached). Syntax is:
> >
> > 	cscript update-test.js URL (username) (passwd)
> >
> > Joe (Orton), in case you read this: it would be nice if Litmus could add
> > some are all of these tests.
> >
> >
> > Julian
> >
> >
> > [1] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16451>
> > [2] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16452>
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
>

Received on Thursday, 30 January 2003 10:19:20 UTC