Qual é o limite em multipart / form-data?

Eu quero fazer uma pergunta sobre o multipart/form-data. No cabeçalho HTTP, acho que o Content-Type: multipart/form-data; boundary=???.

O conteúdo é ???livre para ser definido pelo usuário? Ou é gerado a partir do HTML? É possível definir o ??? = abcdefg?

O conteúdo é ???livre para ser definido pelo usuário?

Sim.

ou é fornecido pelo HTML?

Não. O HTML não tem nada a ver com isso. Leia abaixo.

É possível definir o ???as abcdefg?

Sim.

Se você deseja enviar os seguintes dados para o servidor web:

name = John
age = 12

usando application/x-www-form-urlencodedseria assim:

name=John&age=12

Como você pode ver, o servidor sabe que os parâmetros são separados por um e comercial &. Se &for necessário para um valor de parâmetro, ele deverá ser codificado.

Então, como o servidor sabe onde um valor de parâmetro começa e termina quando recebe uma solicitação HTTP usando multipart/form-data?

Usando o limite , semelhante a &.

Por exemplo:

--XXX
Content-Disposition: form-data; name="name"

John
--XXX
Content-Disposition: form-data; name="age"

12
--XXX--

Nesse caso, o valor limite é XXX. Você o especifica no Content-Typecabeçalho para que o servidor saiba como dividir os dados que recebe.

Então você precisa:

• Use um valor que não apareça nos dados HTTP enviados ao servidor.

• Seja consistente e use o mesmo valor em qualquer lugar da mensagem de solicitação.

A resposta exata à pergunta é: sim, você pode usar um valor arbitrário para o boundaryparâmetro , pois ele não excede 70 bytes de comprimento e consiste apenas em caracteres de 7 bitsUS-ASCII (imprimíveis).

Se você estiver usando um dos multipart/*tipos de conteúdo, precisará especificar o boundaryparâmetro no Content-Typecabeçalho; caso contrário, o servidor (no caso de uma solicitação HTTP) não poderá analisar a carga útil.

Você provavelmente também deseja definir o charsetparâmetro UTF-8no seu Content-Typecabeçalho, a menos que tenha certeza absoluta de que apenas o conjunto de US-ASCIIcaracteres será usado nos dados da carga útil.

Alguns trechos relevantes do RFC2046 :

• 4.1.2 Parâmetro Charset:

  Ao contrário de outros valores de parâmetro, os valores do parâmetro charset NÃO diferenciam maiúsculas de minúsculas. O conjunto de caracteres padrão, que deve ser assumido na ausência de um parâmetro charset, é US-ASCII.

• 5.1 Tipo de mídia multipartes

  Conforme declarado na definição do campo Content-Transfer-Encoding [RFC 2045], nenhuma codificação diferente de "7 bits", "8 bits" ou "binário" é permitida para entidades do tipo "multipart". Os delimitadores de limite "multipartes" e os campos de cabeçalho sempre são representados como US-ASCII de 7 bits em qualquer caso (embora os campos de cabeçalho possam codificar texto de cabeçalho não-US-ASCII conforme RFC 2047) e os dados nas partes do corpo possam ser codificados em um parte por parte, com campos de codificação de transferência de conteúdo para cada parte do corpo apropriada.

  O campo Tipo de conteúdo para entidades com várias partes requer um parâmetro, "limite". A linha delimitadora de limite é então definida como uma linha que consiste inteiramente em dois caracteres de hífen ("-", valor decimal 45) seguidos pelo valor do parâmetro de limite no campo do cabeçalho Content-Type, espaço em branco linear opcional e um CRLF final.

  Os delimitadores de limite não devem aparecer no material encapsulado e não devem ter mais de 70 caracteres, sem contar os dois hífens principais.

  A linha delimitadora de limite após a última parte do corpo é um delimitador distinto que indica que nenhuma outra parte do corpo será seguida. Essa linha de delimitador é idêntica às linhas de delimitador anteriores, com a adição de mais dois hífens após o valor do parâmetro de limite.

Aqui está um exemplo usando um limite arbitrário:

Content-Type: multipart/form-data; charset=utf-8; boundary="another cool boundary"

--another cool boundary
Content-Disposition: form-data; name="foo"

bar
--another cool boundary
Content-Disposition: form-data; name="baz"

quux
--another cool boundary--

multipart / form-data contém limite para separar pares nome / valor. O limite atua como um marcador de cada parte dos pares nome / valor passados ​​quando um formulário é enviado. O limite é adicionado automaticamente ao tipo de conteúdo de um cabeçalho de solicitação.

O formulário com o atributo enctype = "multipart / form-data" terá um cabeçalho de solicitação Content-Type: multipart / form-data; limite --- WebKit193844043-h ( vaue gerado pelo navegador ).

A carga útil passada é mais ou menos assim:

Content-Type: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”file”; filename=”captcha”
    Content-Type:

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”action”

    submit
    -----WebKitFormBoundary7MA4YWxkTrZu0gW--

No lado do serviço da web, é consumido no formato @Consumes ("multipart / form-data").

Cuidado, ao testar seu serviço da web usando o chrome postman, você precisa verificar a opção de dados do formulário (botão de opção) e o menu Arquivo na caixa suspensa para enviar o anexo. O fornecimento explícito de tipo de conteúdo como dados de várias partes / formulário gera um erro. Como o limite está ausente, ele substitui a solicitação de ondulação do postman no servidor com o tipo de conteúdo, acrescentando o limite que funciona bem.

Consulte RFC1341 sec7.2 O tipo de conteúdo de várias partes