beast: Can not read file name with umlauts in boost::beast::http::file_body

Thanks again for the very cool library, first and foremost! We have a minor issue with umlauts (low priority).

Version of Beast

#define BOOST_BEAST_VERSION 290

Steps necessary to reproduce the problem

My code is based on the advanced_server_flex.cpp example, and my problem appears specifically around line https://github.com/boostorg/beast/blob/develop/example/advanced/server-flex/advanced_server_flex.cpp#L179:

    // Attempt to open the file
    beast::error_code ec;
    http::file_body::value_type body;
    body.open(path.c_str(), beast::file_mode::scan, ec);

    // Handle the case where the file doesn't exist
    if(ec == beast::errc::no_such_file_or_directory)  //< This is true for us when the file name has umlauts.

We used this code successfully on multiple platforms (MSVC, Ubuntu and MacOSX) for about a year now. However as soon as we started adding clang-cl to the list of compilers, the webserver can no longer read files that have Umlauts in the file name.

We tested with a file named

üöälaut.txt

that is not found on Windows when using clang-cl, whereas all other platforms/compilers work fine.

All relevant compiler information

The error comes with Visual Studio 2019 x64 16.7.1 with the Microsoft-supplied clang-cl version 10.0.0. Using the Microsoft-Compiler and not clang-cl, everything works.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 39 (14 by maintainers)

Commits related to this issue

Most upvoted comments

@pdimov what do we do

fix the code to not be broken

https://github.com/boostorg/beast/pull/2354 will enable file_win32 on Windows, instead of just on MSVC.

Yes, all these should also check for whether the Microsoft C library is used, and not the specific compiler. _MSC_VER is probably the right thing here.

I’m not sure when the stdio implementation will be used under Windows though, instead of the Win32 one. When BOOST_BEAST_USE_WIN32_FILE is defined by the user to 0, perhaps.

or just #ifdef _MSC_VER

Thanks for responding @emmenlau

What would really help me track this down is:

  1. a simple 10-line program that demonstrates this causing a problem on clang-cl but not on msvc or gcc.
  2. idiot-proof instructions on how to compile and link it 😃

This way I can replicate without too much effort and focus my attention on what is going wrong. It’s beginning to sound as if we’re not detecting Windows properly when compiling on clang (note 1), but I’d like to be able to prove it.

note 1: Because we do have code to detect that we’re on Windows and convert UTF-8 to Windows Unicode internally.

R

ugh, facets…