HTTP: The Definitive Guide

Errata for HTTP: The Definitive Guide

Submit your own errata for this product.


The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.


Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted
PDF Page 56
3rd line, "Response Message", 2st text box, Figure 3-10(Put Example)

Hello, I have borrowed a Chinese printed version of this book from the library of my college, in which book I found this issue. Then I use Google Books to search the similar content in the English PDF version, there is it too. Issue: "Context-Length" in Response Header. It may be "Content-Length". I have searched with Google, to find nothing about the keyword "Context-Length". Besides, this keyword appears several times in this book. Gowe

Gowe Wang  Feb 05, 2016 
PDF Page 83
5th paragraph

In the line "Frequently, the disabled acknowledgment algorithms introduce significant delays", "disabled" should be replaced with "delayed". Should read "Frequently, the delayed acknowledgment algorithms introduce significant delays".

Anonymous  May 08, 2013 
Printed Page 152
First example text under the Via Syntax section

is: Via = 1.1 cache.joes-hardware.com, 1.1 proxy.irenes-isp.net should be: Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com

Anonymous   
Printed Page 152
The "Via" syntax, second example text, needs improvement.

is: Via = "Via" ":" 1#( waypoint ) should be: Via = "Via" ":" ( waypoint )[", " ( waypoint )...]

Anonymous   
PDF Page 183
the first sentence on the 3rd paragraph

"The deprecated Expires header specifies an actual expiration date instead of a time in seconds." Expires header is not deprecated in RFC 2068, RFC 2616 nor httpbis draft. I don't know why the book said it is deprecated.

Yi EungJun  Dec 15, 2013 
Other Digital Version 189
Example 7-1

Errata ID: #zerustech-errata-2016-12-30-10-16 ==================================== The pseudocode in example 7-1 conforms to the specifications till RFC 2616, which has been replaced by RFC 7234 in June, 2014. Unfortunately, the pseudocode is no longer suitable for describing the age calculation algorithm due to the changes in RFC 7234. To keep the chapter of “Age Computation” updated with respect to the latest RFC, the following changes should be applied: $apparent_age = max(0, $time_got_response - $Date_header_value); --- $corrected_apparent_age = max($apparent_age, $Age_header_value); $response_delay_estimate = ($time_got_response - $time_issued_request); +++ $corrected_Age_header_value = $Age_header + $response_delay_estimate; --- $age_when_document_arrived_at_our_cache = $corrected_apparent_age + $response_delay_estimate; +++ $age_when_document_arrived_at_our_cache = max($apparent_age, $corrected_Age_header_value); $age = $age_when_document_arrived_at_our_cache + $how_long_copy_has_been_in_our_cache; Other corresponding parts in this chapter should also be updated accordingly. Note: Figure 7-18 in page 192 should also be changed to reflect the new algorithm and variable names (I will provide the illustration in a separate email shortly). However, please be advised that I submitted errata for “Figure 7-18” on Dec 29, 2016, but that was not for this issue (it was still based on the obsolete specification in RFC 2616). Therefore, if the author were to apply the changes above, the previous errata could be safely ignored.

Michael Lee  Dec 29, 2016 
Other Digital Version 192
Figure 7-18

Two issues were addressed: 1. "The label 'time_got_response' should be moved one node to the right, and the currently labelled node should be removed from the Cache timeline." This has been reported by someone else and has received feedback from the author or editor. 2. The illustrator didn't reflect the fact that the "corrected_apparent_age"—(time_got_response - date_value)— should have been counted twice when calculating the age of the cached document: age_when_document_arrived_at_our_cache = (request_delay_estimate + server_processing_time + response_delay_estimate) + response_delay_estimate. Therefore, to precisely illustrate the calculation algorithm, the timeline and age should be presented separately. I have created a new illustrator and I will send it in a separate email shortly.

Michael Lee  Dec 29, 2016 
PDF Page 194
Example 7-3

is: $age_limit = min($age_limit, server_freshness_limit( ) - $Min_Fresh_value_set); should be: $age_limit = min($age_limit, server_freshness_limit( ) - $Min_Fresh_value); I guess Min_Fresh_value_set is a boolean value to tell whether $Min_Fresh_value is set or not.

Yi EungJun  Dec 14, 2013 
PDF Page 227
5th paragraph

This tag instructs the receiver to treat the document as if its HTTP response header contained a Refresh HTTP header with the value 1, URL=index.html. should be This tag instructs the receiver to treat the document as if its HTTP response header contained a Refresh HTTP header with the value 1; URL=index.html.' (Replace 1, URL=index.html with 1; URL=index.html)

Yi EungJun  May 05, 2014 
PDF Page 227
4th paragraph

<meta http-equiv="Refresh" content="1;URL=index.html"> should be <meta http-equiv="Refresh" content="1; URL=index.html"> (a space character added) Because http://www.w3.org/TR/html-markup/meta.http-equiv.refresh.html says that one or more space characters are required between ";" and "url=".

Yi EungJun  May 05, 2014 
PDF Page 290,292,298

Please replace every "Authorization-Info" with "Authentication-Info". There is no such header as "Authorization-Info".

Yi EungJun  Jun 10, 2014 
Printed Page 292
Figure 13-3. Basic versus digest authentication syntax

In (g) Response, the client make response to the server with "Authorization" header in which "nc=0000001" According to RFC2617 and RFC 7616, nc should be a 8-hex-digit-nonce-count. So, it should be "nc=00000001"

Junlong Zou  Jan 28, 2018 
Printed Page 347
Item 6

This item does not really relate to determining entity body length, and in fact the text of this item is repeated in the following paragraph. Nevertheless, the text of this item is more correct than that of the following paragraph. So the following paragraph should be striken, and the item number should be removed from this item so that the text of this item replaces the following paragraph.

Anonymous   
PDF Page 347
the 3rd paragraph

the full gripped body should be the full gzipped body or the full zipped body (I guess the author tried to write "gzipped" but it was corrected to "gripped" unintentionally)

Yi EungJun  May 15, 2014 
PDF Page 361
Table 15-3. Cache-Control header directives, description of "min-fresh" directive

> The documents age must not be more than its age plus the specified amount. What's the difference between "the document's age" and "its age"? Aren't they same?

Yi EungJun  Feb 22, 2014 
PDF Page 385
4th paragraph

> You can place multiple language tags in the Accept-Language header to enumerate all supported languages and the order of preference (left to right). The order does not matter to the client's preference. RFC 2616 says nothing about the order. And draft-ietf-httpbis-p2-semantics-26 [1] says a sender of the header cannot rely upon the recipient's behavior to accept the order as the sender's language preference, as follows: Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1). However, this behavior cannot be relied upon. For consistency and to maximize interoperability, many user agents assign each language tag a unique quality value while also listing them in order of decreasing quality. Additional discussion of language priority lists can be found in Section 2.3 of [RFC4647]. [1]: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-5.3.5

Yi EungJun  May 18, 2014 
PDF Page 396
Table 17-1. Summary of content-negotiation techniques, "How it works" column of "Transparent" row

The book says: An intermediate device (usually a proxy cache) does the request negotiation on the clients behalf. But RFC 2616 says: Transparent negotiation is a combination of both server-driven and agent-driven negotiation. When a cache is supplied with a form of the list of available representations of the response (as in agent-driven negotiation) and the dimensions of variance are completely understood by the cache, then the cache becomes capable of performing server- driven negotiation on behalf of the origin server for subsequent requests on that resource. So I thinks the intermediate device does the negotiation on the origin server's behalf, not client's.

Yi EungJun  Mar 02, 2014 
PDF Page 419
#3 in Interpreting Host headers

400 Bad Response response is returned to the client. => 400 Bad Request response is returned to the client. ------ 400 HTTP status response means Band Request NOT Bad response.

Sangil.Jeong  Jun 17, 2014 
Printed Page 441
last sentence

403 locked, should be: 423 locked,

Anonymous   
PDF Page 468
7th paragraph

wpad.a.b.microsoft should be: wpad.a.b.microsoft.com

Yi EungJun  Jun 15, 2014 
Printed Page 499
Appendix A: URI Schemes; 3rd paragraph

The IANA also maintains a list of URL schemes, at: should be: The IANA also maintains a list of URI schemes, at:

dmason165  Sep 14, 2016 
PDF Page 509
description for Accept-Charset header

In the description for Accept-Charset HTTP header in Appendix C, every "character set" should be changed to "charset". Why: 1. The table 3-14 and table 17-2 says Accept-Charset header has charsets as its value, not character sets. 2. draft-ietf-httpbis-p2-semantics-22 says, "The "Accept-Charset" header field can be sent by a user agent to indicate what charsets are acceptable in textual response content.".

EungJun Yi  Jul 08, 2013 
PDF Page 511
The description for Authorization header

> See > Chapter 14 for a detailed discussion of the Authorization header. Chapter 14 does not discuss about Authorization header, but 12 and 13 does.

Yi EungJun  Jul 05, 2014 
PDF Page 511
The description for Proxy-Authenticate header

> The full details > of this challenge/response, and other security mechanisms of HTTP, are discussed in detail > in Chapter 14. Chapter 14 does not discuss about that, but 12 and 13 does.

Yi EungJun  Jul 05, 2014 
PDF Page 511
"Authorization" section

> 401 Authentication Required This should be "401 Unauthorized" because "Unauthorized" is the reason phrase for 401 recommended by HTTP/1.1 specification [1]. [1]: https://tools.ietf.org/html/rfc7231#section-6.1

Yi EungJun  Oct 19, 2014 
PDF Page 519
3rd paragraph

In the case of having If-Match header with entity tags, the book says, "The resource is returned only if it has changedthat is, if the previously requested objects entity tag does not match the entity tag of the current version on the server." But I believe it is not correct because the resource is returned only if it has NOT changed. RFC 2616 says in 14.24 If-Match, "If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-Match header) on that resource."

Yi EungJun  Dec 23, 2013 
PDF Page 528
2nd paragraph

> With any header that gives information about the client that otherwise would be unavail- able, there are some security concerns (see Chapter 14 for more information). I can't find the concerns in the chapter. The chapter discusses HTTPS but not other security concerns.

Yi EungJun  Jul 05, 2014 
PDF Page 575
description of "qop" in Table F-1

is: This directive is optional but is made so only for backward compatibility with RFC 2069 [6]; should be: This directive is optional but is made so only for backward compatibility with RFC 2069;

Yi EungJun  Dec 15, 2013