I just want to make a simple module which get uploaded image to a
directory with a custom name. All things seem to be good but
ngx_http_read_client_request_body create local image with the form
header (filename=“test.jpg” Content-Type :application-octet-stream
etc…). Do you know a simple way to remove it ? I want avoid a new
reading from disk.
I just want to make a simple module which get uploaded image to a
directory with a custom name. All things seem to be good but
ngx_http_read_client_request_body create local image with the form
header (filename=“test.jpg” Content-Type :application-octet-stream
etc…). Do you know a simple way to remove it ? I want avoid a new
reading from disk.
Nginx does not decode the request body.
I’m planning to write a function that does the decoding, for use in
mod_wsgi, but I don’t now when I will find the time.
It will not exacly be what you want, but the function can be reused.
If you manage to write such function before me, please let me know (it’s
not an easy task)!
I’m actually working now on the next version of this module which will
be able to cut out and store uploaded files in temporal directory and
proxy the remaining part of the body to a backend with brief information
about files uploaded.
However I’m now faced with a curious problem regarding nginx internals
and I expect a solution in 1-2 weeks.
I’ve forgotten to clarify, that HTML form uploads are encapsulated in
multipart/form-data format, thus “decoding of a request body” in your
case would probably mean “decoding mulipart/form-data”. That’s why my
previous message considers processing of multipart/form-data format.
I’m actually working now on the next version of this module which will
be able to cut out and store uploaded files in temporal directory and
proxy the remaining part of the body to a backend with brief information
about files uploaded.
My idea is to:
Modify the content-type from multipart/form-data to
application/x-www-form-urlencoded
Any non file parts are urlencoded and written to the new body
Files are written to temporary files, and in the new body is written:
name.filename=filename&name.path=path&name.content-type=content-type
where name is the field name and path is the temporary path used to
store the file.
With this method an application needs only to care about urlencoded
request body.
However I’m now faced with a curious problem regarding nginx internals
and I expect a solution in 1-2 weeks.
application/x-www-form-urlencoded
2) Any non file parts are urlencoded and written to the new body
3) Files are written to temporary files, and in the new body is written:
name.filename=filename&name.path=path&name.content-type=content-type
where name is the field name and path is the temporary path used to
store the file.
With this method an application needs only to care about urlencoded
request body.
The problem with application/x-www-form-urlencoded is that it is
percent-encoded and multipart/form-data is not, thus requiring us to
deal with encoding, etc. Dealing with encodings is generally a bad idea
and I prefer to think about request body as a stream of bytes.
Another problem is that if we rename attributes to name.filename= and
name.path= this will require modifying existing applications and such
thing would be quite unuseful.
Therefore what I do now is transferring almost identical request body to
the backend with file fields converted to normal fields containing
following line:
Any non file parts are urlencoded and written to the new body
deal with encoding, etc. Dealing with encodings is generally a bad idea
and I prefer to think about request body as a stream of bytes.
It’s exactly what I want. Many thanks !
Your module should be on NginxModules page
Thanks, but the first version of this module is not mature enough from
my point of view. It solves a problem with extracting files from
multipart/form-data, but it doesn’t solve the problem of handling
uploads them self.
However I’ll appreciate for any constructive feedback about my work.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.