To ignore bad etags or not

[w3c]

To ignore bad etags or not

[sspeiche]

The language you quote is for "If-Modified-Since" and the test in
"testPutBadETags" is testing "If-Match" header usage with PUT.

I don't think there is a problem. testPutBadETags doesn't expect when the
value is "not well-formatted", it is well-formatted entity-tag. It expects
to find a value for ETag such that it won't match a value on the server to
therefore generate the 412 response per the spec.

I can't find any language otherwise in RFC 7232 for If-Match.

Thanks,
Steve Speicher
http://stevespeicher.me

On Wed, Jun 25, 2014 at 4:26 AM, Fernando Serena Acedo <
[email protected]> wrote:

RFC 7232 http://tools.ietf.org/html/rfc7232 says:

"A recipient MUST ignore the If-Modified-Since header field if the
received field-value is not a valid HTTP-date, or if the request method is
neither GET nor HEAD."

Should not the servers behave the same way with bad ETags? Currently,
testPutBadETags expects a 412 when the value is not well-formatted. In that
case, I think LDP servers should ignore the If-Match header and return a
428 (precondition required) or a 2xx.

—
Reply to this email directly or view it on GitHub
#70.

[spadgett]

Reading RFC2616, I believe the only requirement for an ETag is that it's quoted (optionally with a leading W/ for weak ETags). So in that sense the value is well-formed.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19

It might a better test to do one successful PUT first, then try again with the stale ETag value.

[spadgett]

A better link:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11

  entity-tag = [ weak ] opaque-tag
  weak       = "W/"
  opaque-tag = quoted-string

[sspeiche]

Also as we've explored, many implementations don't enforce the quoting.
Though we are a compliance testsuite and should complain when it doesn't
follow the rules.

Thanks,
Steve Speicher
http://stevespeicher.me

On Wed, Jun 25, 2014 at 11:49 AM, Samuel Padgett [email protected]
wrote:

A better link:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11

entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string

—
Reply to this email directly or view it on GitHub
#70 (comment).

[spadgett]

True. And, for what it's worth, testPutBadETag does send a quoted string.

One other point, and then I'll stop spamming :) ...

There's no danger in ignoring a bad If-Modified-Since header because it's simply a caching optimization. Ignoring a bad ETag header, however, could result in data loss.

[fserena]

I agree.

But although it seems common sense once discussed, this behavior is not described in the specification. I mean, I'm afraid that nowhere says that if the ETag is badly formatted the server should return a 412.

[sspeiche]

We are sending a properly formatted but non-existant ETag. So we are testing 412 in that case. I could see strict servers returning any of a number of possible 4xx values if ETag was formatted improperly or just accepting it.