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. On Oct 21, 2:00 pm, Alan Williamson <[EMAIL PROTECTED]> wrote: > aaaah a fellow nginx user -- i welcome you with open arms. I know this > engine very well (way more than i ever wanted to i can assure you!) > > How convinced are you that OpenBD isn't setting the header attribute > properly? > > Have you an example of what it should be, and what OpenBD is producing? > > Also, how sure are you that nginx isn't stripping it? nginx will strip > quite alot even in a proxying environment. > > Brad B. wrote: > > Yeah ok, I've been trying to pass an X-Accel-Redirect header to nginx > > with filenames that have foreign characters in them and every time i > > set the charset attribute cfheader appears to remove the filename from > > the value. It's an old issue for me and I have been coming back to it > > every so often but just can't seem get it squared away. :p Sadly > > though, if no charset is set the value of the filename passed by the > > header is all garbled. I feel like it's something simple now that i'm > > missing. It's pretty frustrating. --~--~---------~--~----~------------~-------~--~----~ 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 !! -~----------~----~----~----~------~----~------~--~---
