You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that the :external-format-out parameter is not taken into account for the filename header at all. Neither setting drakma:*drakma-default-external-format* or an implementation specific default encoding variable seems to have any effect.
The text was updated successfully, but these errors were encountered:
Shinmera
added a commit
to Shirakumo/filebox-client
that referenced
this issue
Dec 8, 2014
<fe[nl]ix> H4ns: you have to encode the UTF8 file name to octets, then encode
octets to ASCII using URL-encoding, then split the header onto
multiple lines if the name is too long
<fe[nl]ix> and to specify that the multiple parameters of content-disposition
are to be concatenated, the parameters must have an index suffix
<fe[nl]ix> so instead of name="foo.jpg", you have name*0="start"\r\n
name*1="end"
<fe[nl]ix> H4ns: and you can(must in practice?) also specify the encoding
<fe[nl]ix> see section 4.1 of https://tools.ietf.org/html/rfc2231
Also, the file name parameter to Content-Disposition should be "filename", not "name". I suppose that many servers recognize the latter for robustness, but it's non-standard.
How to reproduce (the pathname does not have to exist on the system):
Expected behaviour: Sending the file with the filename encoded in utf-8
What happens instead:
It seems that the
:external-format-out
parameter is not taken into account for the filename header at all. Neither settingdrakma:*drakma-default-external-format*
or an implementation specific default encoding variable seems to have any effect.The text was updated successfully, but these errors were encountered: