175641 - Inappropriate behavior on a 412 response

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Daniel Hellerstein]

While testing the SREhttp/2 http/1.1 web server, I uncovered what I believe
to be a bug in how the IBM Web Browser 2.0 deals with If-None-Match.

1) The browser:
Mozilla
IBM Web Browser for OS/2 Version 2.0
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.0.1) Gecko/20020919 IBM Web Browser
for OS/2

2) The problem.
  a) the browser requests  a script, using a method="POST" HTML form.
  b) the server returns a response with an etag (say, with value "ABC")
  c) a minute or so after recieving and displaying this response, 
     the client hits "Reload" (he answers yes to the POSTDATA message box)
  d) the browser sends a request, with an If-None-Match: "ABC"
     request header 
  e) assume the contents of the response (to this Reload request) doesn't     
     change. Hence the etag for the response, to this 2nd request,
     also does not change -- it is still "ABC". 
     Since the If-None-Match Etag sent by the browser matches (they are
     both "ABC"), the server returns a 412 Precondition Failed response)
  f) The browser displays the nominal message included with this response

Step f is INCORRECT. The browser should display the cached item corresponding
to this resource and etag. 

The problem I believe is that the browser is expecting a 304 response, which
would be appropriate if the request was GET method. However, per  
section 14.26 of RFC2616 (the http/1.1 spec)...

   Instead, if the request method was GET or HEAD, the server SHOULD
   respond with a 304 (Not Modified) response, including the cache-
   related header fields (particularly ETag) of one of the entities that
   matched. For all other request methods, the server MUST respond with
   a status of 412 (Precondition Failed).

So this is a problem. Either I (the server author) go against spec and
return a 304, or I suppress checking etags on post requests.


Please contact me ([e-mail]) and I can set up a demo
(on the srehttp2.srehttp.org site)

Comment 1

[Alex Bishop]

*** Bug 175638 has been marked as a duplicate of this bug. ***

Comment 2

[Alex Bishop]

-> Browser/Networking: HTTP (as per bug 175638).

Comment 3

[Darin Fisher]

wow!  now isn't that interesting.  i wonder what the motivation is for this...
is there something vague about responding with 304?  anyways, this is something
we can easily fix.

Comment 4

[Bradley Baetz (:bbaetz)]

You can't responsd with a 304 per se, because the idempotent part of the spec -
the POST is allowed to have secondary side effects - if I buy a car 5 times,
I'll still get the same thank you screen. Thats a guess, mind you.

Section 9.5 says: 'Responses to this method [POST] are not cacheable, unless the
response includes appropriate Cache-Control or Expires header fields'. If its
not cachable, sending an If-Match header is inappropriate, I suppose.

Comment 5

[Darin Fisher]

ok, i'm probably just going to go the safe route and act like we never have a
POST or PUT response in our cache.  there doesn't seem to be much application
for POST or PUT response validation in mozilla.

Comment 6

[Darin Fisher]

Attachment: v1 patch

simple patch: respond to 412 as we would respond to 304.  this works given the
limited use of conditional requests in mozilla.

Comment 7

[Bradley Baetz (:bbaetz)]

Comment on attachment 106693 [details] [diff] [review]
v1 patch

OK, I guess. This isn't really correct - its a moz bug that we're sending the
If-Modified request at all. Can you file a separate bug on that?

Comment 8

[Darin Fisher]

bbaetz:

is it really a bug to send a conditional POST/PUT?  where does it say that in
the RFC?  instead, it seems like the RFC allows for these requests to be
conditional (the section on If-None-Match makes explicit mention of POST
requests afterall).  anyways, i think we can safely leave it up to the servers
to decide if a conditional POST/PUT request should be answered with a 412
instead of a 200.

a web application might take advantage of conditional POST requests :-/

Comment 9

[Bradley Baetz (:bbaetz)]

Weel, section 14.26 talks about if-none-match, and says that any server MUST
send back a 412 in that case. So we're not prohibited for us to send one, but
since we cna predict the result theres not much point.

Its allowed for PUT because we might want to PUT a file only if it doesn't
exist. That semantic doesn't really hold for POST - PUT creates/replaces an
entity, whereas POST uses a location to do something with a provided entity.
Does that sound logical?

Comment 10

[Daniel Hellerstein]

I agree with Darin -- it's not a bug. It can even be sensible -- if
the response is rather lengthy, but has not changed (as evidenced by
the etag not changing) it is more efficient to return a 412.

So, either the client should NOT send an if-none-match on POST 
requests, or it should be prepared to display a cached version from an 
earlier response(precisely, from an earlier response identified by the 
etag the client includes in the if-none-match request header).

I vote for the second, but since I won't be implementing it, my top
priority is that one or the other (or the above alternatives) occur.
I do NOT want to force my server to try to figure out the appropriate 
action based on User-Agent!

Comment 11

[Darin Fisher]

Attachment: v2 patch

OK, i think this is a better patch to go with.	it suppresses If-Modified-Since
and If-None-Match for any request other than GET or HEAD.  We can revisit
supporting conditional POST/PUT if the need arrises.

Comment 12

[Darin Fisher]

adding testcase: http://unagi.mcom.com/bugs/bug_175641/test.html

(1) load testcase URL
(2) press submit
    - should see "OK"
(3) press browser reload button
(4) press OK to the resubmit POSTDATA warning dialog
    - should see "OK" if bug is fixed

Comment 13

[Darin Fisher]

fixed-on-trunk

Comment 14

[John Unruh]

Verified.