Атрибуты Content-Type MultipartBody, сброшенные на CXF Upgrade

После обновления Apache CXF с 2.4.0 до 3.1.4 заголовок Content-Type по ответам от JAX-RS-методов отбросил несколько атрибутов.Атрибуты Content-Type MultipartBody, сброшенные на CXF Upgrade

Под CXF 2.4.0, жатка:

Content-Type: multipart/mixed; type="application/octet-stream"; boundary="uuid:61b631f1-0aa9-4cc8-ad85-3c09129ec442"; start="<DocumentName.ext>"; start-info="application/octet-stream"

Под CXF 3.1.4, это:

Content-Type: multipart/mixed; boundary="uuid:804168d7-70ed-44e7-a471-9647372b9224"

Примечание: атрибуты type, start, start-info отсутствует.

Вот код, который мы используем:

@GET 
@Path("{order_id}/document/{document_id}/file") 
@Produces("multipart/mixed") 
public MultipartBody getDocument(@PathParam("order_id") int _orderId, @PathParam("document_id") int _documentId) throws Exception { 

    FileInfo fileInfo = findFileInfo(_orderId, _documentId); 

    List<Attachment> atts = new ArrayList<Attachment>(); 

    File internalFile = fileInfo.getActualFile(); 

    String fileName = fileInfo.getOriginalDocumentName(); 

    String fileSize = String.valueOf(internalFile.length()); 

    ContentDisposition cd = new ContentDisposition("attachment; filename=\"" + fileName + "\"; size=" + fileSize); 

    InputStream inputStreamToUse = new FileInputStream(internalFile); 

    Attachment att = new Attachment(fileName, inputStreamToUse, cd); 

    atts.add(att); 

    return new MultipartBody(atts, true);  
}

Я не могу найти никаких ссылок в Migration Guides к изменениям в этой области и стиля выше метода, кажется, соответствует одному из getBooks2() method in the JAX-RS Multipart documentation.

Любые указания относительно того, что может вызывать различное поведение?

источник

2016-01-04 Jacob Zwiers

Возможно, но не уверены. Множество клиентов веб-службы, не все из которых способны тестировать, и мы хотели бы гарантировать совместимость перед публикацией новой версии сервиса, которая только (в данном случае), и обновления до CXF и минимальных изменений, необходимых для компиляции. Помимо этого, базовый код не изменился. Если CXF установил более раннюю проблему, когда эти атрибуты не должны были быть включены, это было бы приемлемым объяснением и сделало бы любые клиенты, которые полагались на нее, соответствовали. –

Поскольку ваш мультипартик имеет только одну часть (на основе кода, который вы предоставляете), имеет смысл, что «старт» (используемый для идентификации первой части, так как multipart/mixed упорядочен) был отброшен; для «start-info». Что касается «типа», я не знаю, но не слишком беспокоился об этом, поскольку он определен для части ниже любым способом. – smarquis

Итак, @smarquis, вы предполагаете, что CXF прекратил генерировать атрибут type, потому что он избыточен, учитывая то, что следует, и атрибуты start-info и start, потому что они были ошибочно (или избыточно) добавлены для одночастных тел? –

Это было сделано, потому что, по-видимому, только multipart/related тип носителя может быть дополнительно start и start-info атрибутов в соответствии с http://tools.ietf.org/html/rfc2387.

Более полное обсуждение этой темы содержится в списке рассылки CXF, в частности this message, что указывает на то, что Content-Type также был сломан.

источник

2016-01-11 12:07:43

Атрибуты Content-Type MultipartBody, сброшенные на CXF Upgrade

ответ

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