Заборона HTTP-методів у Tomcat чутлива до регістру?

Я вклав наступне у web.xml моєї програми, щоб спробувати заборонити PUT, DELETE тощо:

 <security-constraint>
 <web-resource-collection>
  <web-resource-name>restricted methods</web-resource-name>
  <url-pattern>/*</url-pattern>
  <http-method>DELETE</http-method>
  <http-method>PUT</http-method>
  <http-method>SEARCH</http-method>
  <http-method>COPY</http-method>
  <http-method>MOVE</http-method>
  <http-method>PROPFIND</http-method>
  <http-method>PROPPATCH</http-method>
  <http-method>MKCOL</http-method>
  <http-method>LOCK</http-method>
  <http-method>UNLOCK</http-method>
  <http-method>delete</http-method>
  <http-method>put</http-method>
  <http-method>search</http-method>
  <http-method>copy</http-method>
  <http-method>move</http-method>
  <http-method>propfind</http-method>
  <http-method>proppatch</http-method>
  <http-method>mkcol</http-method>
  <http-method>lock</http-method>
  <http-method>unlock</http-method>
 </web-resource-collection>
 <auth-constraint />
 </security-constraint>

Гаразд, тепер:

Якщо я роблю запит методом, DELETEя отримую 403 назад.

Якщо я роблю запит методом, deleteя отримую 403 назад.

АЛЕ

Якщо я роблю запит методом, DeLeTeя отримую нормально!

Як я можу зробити так, щоб заборонити ці чутливі до регістру справи?

Редагувати: я тестую його за допомогою програми C #:

    private void button1_Click(object sender, EventArgs e)
    {
        textBox1.Text = "making request";
        System.Threading.Thread.Sleep(400);
        WebRequest req = WebRequest.Create("http://serverurl/Application/cache_test.jsp");
        req.Method = txtMethod.Text;
        try
        {
            HttpWebResponse resp = (HttpWebResponse)req.GetResponse();

            textBox1.Text = "Status: " + resp.StatusCode;

            if (resp.StatusCode == System.Net.HttpStatusCode.OK)
            {
                WebHeaderCollection header = resp.Headers;
                using (System.IO.StreamReader reader = new System.IO.StreamReader(resp.GetResponseStream(), ASCIIEncoding.ASCII))
                {
                    //string responseText = reader.ReadToEnd();
                    textBox1.Text += "\r\n" + reader.ReadToEnd();
                }
            }
        }
        catch (Exception ex)
        {
            textBox1.Text = ex.Message;
        }
    }

txtMethod.Textце текстове поле, де я набираю ім'я методу. Коли є 403, викидається виняток, який потрапляє у блок лову.

Cache_test.jsp містить:

<%
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate, post-check=0, pre-check=0");
response.setHeader("Pragma","no-cache");

out.print("Method used was: "+request.getMethod());
%>

Незалежно від неправильної поведінки Tomcat щодо стандарту HTTP, вам слід використовувати білий список, щоб дозволити конкретні методи, а не чорний список.

Наприклад, наступний білий список блокує всі методи, окрім регістру GET та " HEAD.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>restricted methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method-omission>GET</http-method-omission>
        <http-method-omission>HEAD</http-method-omission>
    </web-resource-collection>
    <auth-constraint />
</security-constraint>

(Примітка: потрібен Tomcat 7+. Тим, хто використовує старіші версії, доведеться досліджувати інші рішення, наприклад, фільтр сервлетів.)

Реф

Ну, після швидкого тестування на деяких випадкових серверах, що тримають Server: Apache-Coyotteпідпис заголовка у своїх відповідях HTTP, здається, ви праві, оскільки надсилання get / HTTP/1.1\r\nHost: <target_IP>\r\n\r\nпростим мережним з'єднанням працювало кожен раз, тоді як 400 HTTP-код повинен був бути отриманий.

Наприклад :

$ { echo -en "get / HTTP/1.1\r\nHost: <target_IP>:8080\r\n\r\n" ; } | nc <target_IP> 8080

01:14:58.095547 IP 192.168.1.3.57245 > <target_IP>.8080: Flags [P.], seq 1:42, ack 1, win 115, options [nop,nop,TS val 4294788321 ecr 0], length 41
E..]C.@.@..Y......p.....A..v.......s.......
..D.....get / HTTP/1.1
Host: <target_IP>:8080

[...]

01:14:58.447946 IP <target_IP>.8080 > 192.168.1.3.57245: Flags [.], seq 1:1409, ack 43, win 65494, options [nop,nop,TS val 7981294 ecr 4294787971], length 1408
E...f...i.....p.............A..............
.y....C.HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Tue, 27 Jan 2015 00:15:14 GMT

Треба сказати, що я трохи шокований тут, і я не був би здивований, побачивши, що в такому випадку поведінка поширюється на всі методи HTTP / 1.1.

Вам слід заповнити звіт про помилки на їхньому інструменті відстеження помилок та надіслати пошту у відповідний список розсилки, оскільки це одне некрасиве порушення RFC 2616 (див. Нижче) із поганими наслідками.

5.1.1 Метод

  The Method  token indicates the method to be performed on the
  resource identified by the Request-URI. The method is case-sensitive.

      Method         = "OPTIONS"                ; Section 9.2
                     | "GET"                    ; Section 9.3
                     | "HEAD"                   ; Section 9.4
                     | "POST"                   ; Section 9.5
                     | "PUT"                    ; Section 9.6
                     | "DELETE"                 ; Section 9.7
                     | "TRACE"                  ; Section 9.8
                     | "CONNECT"                ; Section 9.9
                     | extension-method
      extension-method = token