Bug 57358

Summary:	Incorrect If-Match handling
Product:	Apache httpd-2	Reporter:	Kunihiko Sakamoto <ksakamoto>
Component:	Core	Assignee:	Apache HTTPD Bugs Mailing List <bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ksakamoto, wiml
Priority:	P2	Keywords:	FixedInTrunk, PatchAvailable, PortBack
Version:	2.5-HEAD
Target Milestone:	---
Hardware:	All
OS:	All
Attachments:	Patch

Description Kunihiko Sakamoto 2014-12-17 01:32:33 UTC

Handling of If-Match header (RFC 2616, Section 14.24) seems to be broken. See an example session below:


# Obtain ETag

GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 16 Dec 2014 02:27:48 GMT
Server: Apache/2.4.10 (Unix)
Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT
ETag: "2d-432a5e4a73a80"
Accept-Ranges: bytes
Content-Length: 45
Connection: close
Content-Type: text/html

<html><body><h1>It works!</h1></body></html>


# If-Match with ETag => OK

GET / HTTP/1.0
If-Match: "2d-432a5e4a73a80"

HTTP/1.1 200 OK
Date: Tue, 16 Dec 2014 02:28:33 GMT
Server: Apache/2.4.10 (Unix)
Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT
ETag: "2d-432a5e4a73a80"
Accept-Ranges: bytes
Content-Length: 45
Connection: close
Content-Type: text/html

<html><body><h1>It works!</h1></body></html>


# If-Match: * => WRONG, should return 200

GET / HTTP/1.0
If-Match: *

HTTP/1.1 412 Precondition Failed
Date: Tue, 16 Dec 2014 02:28:43 GMT
Server: Apache/2.4.10 (Unix)
Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT
ETag: "2d-432a5e4a73a80"
Accept-Ranges: bytes
Content-Length: 0
Connection: close
Content-Type: text/html


# ETag doesn't match => WRONG, should return 412

GET / HTTP/1.0
If-Match: "xyzzy"

HTTP/1.1 200 OK
Date: Tue, 16 Dec 2014 02:28:53 GMT
Server: Apache/2.4.10 (Unix)
Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT
ETag: "2d-432a5e4a73a80"
Accept-Ranges: bytes
Content-Length: 45
Connection: close
Content-Type: text/html

<html><body><h1>It works!</h1></body></html>

Comment 1 Kunihiko Sakamoto 2014-12-17 01:35:10 UTC

Created attachment 32297 [details]
Patch

Comment 2 Ruediger Pluem 2014-12-17 15:40:40 UTC

Committed a slightly different version in r1646282 to trunk. Thanks for the pointer.

Comment 3 Wim Lewis 2015-03-10 23:23:10 UTC

Confirming that the bug is fixed in recent (r1665385) trunk (2.5 dev).

I'd like to propose this to be backported to the 2.4 branch, since it's a regression and can cause loss of data if a client is relying on the functionality. (The bug appeared between the 2.4.4 and 2.4.6 releases, and exists up though 2.4.12 and the current (r1665231) 2.4.x-branch head.)

Comment 4 Yann Ylavic 2015-03-10 23:52:04 UTC

Backport to 2.4.x proposed in r1665739.

Comment 5 Christophe JAILLET 2015-06-27 07:16:53 UTC

This is part of the (unreleased) 2.4.13
backport in r1674658