yep it's proxying to a Resin container running OpenBD, OpenBD sends the header x-accel-redirect and nginx intercepts it and serves the file set in that header's value. In this case, OpenBD is sending garbled characters when the filename contains characters other than ascii characters.
On Oct 21, 2:21 pm, Alan Williamson <[EMAIL PROTECTED]> wrote: > i am a little unclear here what role OpenBD has in the equation. > > is nginx sitting infront of openbd proxying requests? > > Is nginx attempting to deliver this directly? If so, is that not an > nginx issue? Have you tried their mailing list? Igor, the main man > behind nginx is very active and quick to respond. > > Brad B. wrote: > > Cool. > > The filename i've been testing with is /srv/files/人人素個撮影物.jpg > > (hopefully that's safe for work i don't read chinese :o) > > and nginx error log tells me: > > 2008/10/21 14:29:26 [error] 3423#0: *96 open() "/srv/files/ > > qi.jpg" failed (2: No such file or directory) > > > All other us-ascii files i've tried work fine even when setting the > > charset. As for nginx stripping this, I'm not sure how I would check > > that - with charset value set to any value listed the X-Accel-Redirect > > value is set just fine just not with any filenames contain foreign > > characters. I've been reviewing the nginx docs, and have tried > > numerous combinations of charset values in nginx.conf - with no > > change. --~--~---------~--~----~------------~-------~--~----~ Open BlueDragon Public Mailing List http://groups.google.com/group/openbd?hl=en official blog @ http://blog.openbluedragon.org/ !! save a network - trim replies before posting !! -~----------~----~----~----~------~----~------~--~---
