6

Я занимаюсь разработкой Spring MVC приложение с рамочным 3.2.3.RELEASESpring MVC Framework: MultipartResolver с помощью метода PUT

В моем приложении я справиться Multipart с StandardServletMultipartResolver, но с Apache Commons-FileUpload 1.3 вещи являются одна и та же.

Хотелось бы знать, почему реализация метода isMultipart учитывает только метод POST, а не метод PUT. Если я хочу обновить сущность и связанный файл, я должен сделать это с помощью POST.

Глядя на org.springframework.web.multipart.support.Standard ServletMultipartResolver:

public boolean isMultipart(HttpServletRequest request) { 
    // Same check as in Commons FileUpload... 
    if (!"post".equals(request.getMethod().toLowerCase())) { 
     return false; 
    } 
    String contentType = request.getContentType(); 
    return (contentType != null && contentType.toLowerCase().startsWith("multipart/")); 
} 

в org.apache.commons.fileupload.servlet.ServletFileU pload у меня есть:

public static final boolean isMultipartContent(HttpServletRequest request) { 
    if (!POST_METHOD.equalsIgnoreCase(request.getMethod())) { 
     return false; 
    } 
    return FileUploadBase.isMultipartContent(new ServletRequestContext(request)); 
} 

Это не жизненно важное значение, на самом деле просто используйте метод POST для работы PUT. Но я хочу понять, почему PUT не учитывается!

Спасибо за любой ответ Marco

ответ

11

RFC сказал

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

URI, в запросе POST идентифицирует ресурс, который обрабатывает включенный объект. Этот ресурс может быть процессом принятия данных, шлюзом к другому протоколу или отдельным объектом, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный с запросом - пользовательский агент знает, что такое URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к другому ресурсу.

Таким образом, запрос PUT представляет собой единственный ресурс.
Но multiparts означает несколько ресурсов в одном теле.

http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

В случае нескольких сообщений части, в которых один или несколько различных наборы данных объединены в одном теле, «многочастное» Content-Type поле должно отображаться в заголовке лица , Затем тело должно содержать одну или несколько «частей тела», каждая из которых предшествует границе инкапсуляции, а последняя - закрывающейся границей.

Таким образом, семантика запроса PUT не совпадает с многочастными данными. И POST сопоставляется, потому что запрошенный URI запроса POST является «обработчиком закрытых объектов».

1

PUT относится к одному ресурсу, например один файл. Таким образом, по определению, многочастная форма не соответствует глаголу PUT.

Так что я предполагаю, что они сделали эти чеки для POST, чтобы иметь возможность обратиться к HTTP спецификации: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Я думаю, вы можете возразить, что Положив пользовательский объект, который содержит несколько полей, в том числе один или несколько файлов, должно быть в порядке, его все равно можно считать одним ресурсом в терминах REST, но это не так, как кажется большинству исполнителей.

Смежные вопросы