fix incorrect partial content response to HEAD request with-Range-header, or from Not-accept-range server

[Chenjp]

• Bug: incorrect partial content response to HEAD request with-Range-header
  Tomcat - 206:

    C:\Users\chenjp>curl http://localhost:55263/index.html -i -H "Range: bytes=0-10" -I
    HTTP/1.1 206
    vary: accept-encoding
    Accept-Ranges: bytes
  

  www.apache.org offcial site - 200:

  C:\Users\chenjp>curl https://www.apache.org -i -H "Range: bytes=0-10" -I
  HTTP/1.1 200 OK
  Connection: keep-alive
  Content-Length: 64483
  

• Bug: receives a partial content sc from a Not-accept-range server (DefaultServlet with init param useAcceptRanges=false)

  C:\Users\chenjp>curl http://localhost:55463/index.html -i -H "Range: bytes=0-10"
  HTTP/1.1 206
  vary: accept-encoding
  ETag: W/"957-1732881015126"
  

ChangeLog:

• per RFC 9110 - Section 14, currently GET is the only method.
• A server that turn off accept-range support should ignore Range header field.

[markt-asf]

Needs some small changes but I'll do that after merging but before back-porting.

[markt-asf]

Note: It is not required for a server to send Accept-Ranges for it to process a request with Range.

[Chenjp]

Note: It is not required for a server to send Accept-Ranges for it to process a request with Range.

Does value of useAcceptRanges determine the server enable / disable feature Range Requests?

[markt-asf]

No.

[Chenjp]

If app developer decide to disable Range Requests feature, how to?

[markt-asf]

If they really want to do that - and I can't think of a valid reason they would - they can write a Filter (or Valve) to remove the Range header.

[Chenjp]

Since the Range Requests feature is optional, may a reason stand there.
This feature affects the "Accept-Range" header of responses, and server behavior for requests (with "Range“, "If-Range" headers).
Filter/Valve is ok. Or DefaultServlet introduce an init parameter or new method protected boolean isRangeRequestsSupported() to control this feature, which can be processed easily in #serveResource.

[Chenjp]

No.

If a server has Range-Requests feature enabled and the target resource also supports it, I think no good reason to turn off the Accept-Ranges: bytes response header, especially for those large-content resources.

[markt-asf]

Look at the history of the code. You'll need to go back a long way. There is definitely an argument for deprecating this option and removing it in Tomcat 12.