proxy_pass + "Content-Type" again. #1456
Comments
|
@ecc256 Recently we fixed bugs in this part. Will you please try the following preview version of OpenResty on your side? If you still have problems, please let us know by following up here. Sorry for the delay on our side. |
No problem at all! I don’t see any changes for my case. Scenario: Question:
BTW: Let me know if further clarification or tests are needed, please. |
|
@ecc256 OK, I see your requirement now. I've just prepared and tested the following minimal and standalone example, which should serve you well: http {
init_by_lua_block {
require "resty.core"
require "ffi".cdef[[
uintptr_t ngx_http_set_content_type(void *r)
]]
}
server {
listen 8080;
location ~ '^/t/(.*)' {
types {
text/html html htm shtml;
text/css css;
text/xml xml;
image/gif gif;
}
proxy_pass $scheme://127.0.0.1:$server_port/$1;
header_filter_by_lua_block {
ngx.header["content-type"] = nil
local get_req = require "resty.core.base".get_request
require "ffi".C.ngx_http_set_content_type(get_req())
}
}
location /fake-backend/ {
content_by_lua_block {
ngx.header["Content-Type"] = 'application/octet-stream';
ngx.say("ok")
}
}
}
}And then we query the proxy locations with different file extensions: $ curl -i localhost:8080/t/fake-backend/a.html
HTTP/1.1 200 OK
Server: nginx/1.15.8 (no pool)
Date: Mon, 04 Feb 2019 23:09:42 GMT
Content-Type: text/html
Content-Length: 3
Connection: keep-alive
ok
$ curl -i localhost:8080/t/fake-backend/a.css
HTTP/1.1 200 OK
Server: nginx/1.15.8 (no pool)
Date: Mon, 04 Feb 2019 23:09:48 GMT
Content-Type: text/css
Content-Length: 3
Connection: keep-alive
okThe Content-Type is indeed varying. And we can try accessing the fake backend location directly: It's indeed always Yeah, it uses a hack to achieve this. It would be better to prepare a Lua library to encapsulate this hack :) |
|
@agentzh,
I do disagree respectfully! I use it in few locations, so I’ve rewrote your code with header_filter_by_lua_file as: local base = require "resty.core.base"
local ffi = require "ffi"
local C = ffi.C
ffi.cdef[[
uintptr_t ngx_http_set_content_type(void *r)
]]
local get_request = base.get_request
ngx.header["content-type"] = nil
C.ngx_http_set_content_type(get_request())
It works great! Tiny question (unrelated to the issue): You use Last thing (unrelated to the issue): And thanks a lot for your help and for great example! BTW: Should it be: |
|
@ecc256 No, do not call ffi.cdef() in a request handler directly since it is VERY SLOW and also leaks memory. Call it in |
|
@ecc256 Calling |
|
There is one missing thing in my example, BTW. We should check the return value of the |
|
@agentzh, local ffi = require "ffi"
ffi.cdef[[
uintptr_t ngx_http_set_content_type(void *r)
]]into init_worker_by_lua_file!
Even if it fails, what would be the right thing to do? Thanks for the lesson! 👍 |
The former form is a little bit faster.
Well, that is actually NGINX's C API. Because NGINX does not have the concept of an ABI, it may break in a future nginx release. Fortunately for this particular C API function, it hasn't changed for years. Beware though.
Well, you just need to enable this module by passing
No, this example wants to proxy to |
Well, |
I see.
Got it.
Got it!
I’m a bit confused about right To clarify, you comment means the correct line is:
|
|
@ecc256 That |
Guys,
Want to bring up old question.
It’s not a bug, I’m just trying to understand behavior and find right course of actions.
I did lots of Googling, but didn’t find definitive answer.
(Openresty version is at the very bottom of the post.)
In short:
Static files are stored on Azure storage.
There is a "location" configured for such files which performs uri rewrite, adds sas token to and does
proxy_pass http://qamfiles.file.core.windows.net;It works fine.
The only wrinkle is "Content-Type" returned by proxy (i.e. Azure storage http endpoint) is "application/octet-stream" always.
Requested file extension is known and proper "Content-Type" can be set easily from header_filter_by_lua_file code.
Question:
Is there a better way to tell OpenResty to update "Content-Type" header according to the file type after proxying?
If not, I assume, "mime.types" file is loaded somewhere into memory.
Is it possible to access it (as a table?) from LUA code directly instead of essentially duplicating its content (in LUA code)?
lua_use_default_type setting for the location has no effect and is right behavior, apparently.
Not sure if it’s related to 1449
Thanks!
I didn’t provide config example, I it’s not needed for this case.
The text was updated successfully, but these errors were encountered: