Skip to main content

Public

Project privacy set to public. By default, its content is available to everyone (authenticated or not). Please note that more restrictive permissions might exist on some items.

    •  
      request #14188 Download changes filenames containing non-ASCII characters
    Actions
    Infos
    #14188
    Jérôme Averty (javerty)
    2019-11-18 12:31
    2019-11-15 17:23
    15447
    Details
    Download changes filenames containing non-ASCII characters

    Process : In Docmument service,

    • Add "Test accents é ù à ë ô Ref123.docx"
    • Download this document
    • => The Document's name is now "Test accents Ref123.docx"

    It's problematique for reference's documents.

    Doc/Documentation manager
    All
    Empty
    • [ ] enhancement
    • [ ] internal improvement
    Empty
    Stage
    Empty
    Verified
    Empty
    Attachments
    Artifact links
    Empty
    Empty
    References
    References list is empty
    Display settings

    Follow-ups

    User avatar
    Thomas Gerbet (tgerbet)2019-11-18 12:31
    You guessed correctly @atisne this is intentional to not break browsers or tools that needs to interact with it.

    The Content-Disposition header is a mess. Technically to support both something that works almost everywhere and supports modern tools we need to add a filename* section in the header. This is covered by RFC2231 and RFC5987.
    • Status changed from New to Verified
    • Platform cleared values: CentOS 6
    User avatar
    Aurélien Tisné (atisne)2019-11-18 11:45
    • Summary
      -Management of accented documents in documents service 
      +Download changes filenames containing non-ASCII characters 
    User avatar
    Aurélien Tisné (atisne)2019-11-18 11:39
    If this behavior intends to avoid encoding issues in HTTP headers, it's a bit radical.
    Even if all browsers don't manage encoding in HTTP headers in the same way, the best choice may be to implement the current RFC at the charge of browsers to be compliant with standard recommendations. It should not be worse than today.

    RFC 2183 [https://tools.ietf.org/html/rfc2183] says:
    "Parameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in [RFC 2184]."
    RFC 2184 was obsoleted by RFC 2231[https://tools.ietf.org/html/rfc2231].