Handlers for uploaded files, handlers for calculating hash

[d-nikulin]

Right now for PUT&POST requests uploaded files (attachments) are written to a temporary file. Sometimes it's suboptimal, since the user would likely want to do something with the attachment immediately, for example to redirect input stream for another service excluding writing to the File System. So, i make pointers into a listen_point for mks_temp, write, close, unlink functions, user can redefine them by own callbacks.

Also, i add functionality for calculating hash for attachment content. Now this feature realized only for PUT request.

This PR makes a user to be able to set custom function-handlers to do something with the attachment.

[Hi-Angel]

I looked at the 2-nd and 3-rd commits, named attr and post_attachment_handlers, and I'd say, it's impossible to understand what' going on. The commit title is unclear, inside the commit you do a lot of irrelevant changes, such as renaming local variables.

You might want to read this article for starters.

[davidmoreno]

Hi,

Thank you very much for the patch. I like a lot the way to solve to save the data to other places, not just files. That's a fantastic way to do it!

On the other hand I'm worried that the hash calculation is too much specific for your use case. Normally I don't check the hash of the received files, and there are not many situations where I think it may be necessary. I'm open to change my mind with good arguments.

But else I think that for your case a little more complex file writer can do the trick. It can work as a splitter that from one file creation opens two places to store the data, and on each write stores it in both places: one for real storage, the other calculate the hash.

I leave some comment on the code.

Also I would appreciate some test, for example to use malloc and free to store a file in memory.

[d-nikulin]

Hi, David.

try to explain for you my opinion.

1) the way for writing an attachment into a memory or filesystem. Sometimes web server got a big data, in this case store it to ram isn't acceptable. i think the decision for way storing data, depends for http request context Only a flag for this decision, i think, isn't enough and flexibly. http requests have various context, and so must have various way executing them. By this way, any user, can realize the way for storing into memory. We can write standard handlers for this way. So, i think, the way to delegate this decision (way to store data) according to request context for user level is a good idea.

2) hash code. i think it is very useful feature. it isn't a problem if received data has little size. But if we got big data & we need to calculate a hash for content the task hasn't acceptable decision. On another way, by default, hash code handlers set to NULL, and so hasn't decrease performance. Also a few code strings implements this feature. The code complexity isn't increases implementing this feature.

3) About " .. little more complex file writer can do the trick .. "
i think if you accept my idea of using callbacks for storing content, this functionality can be realized inside them, but it increases user callbacks code complexity. By my way, this feature will be acceptable using default store handlers (mks_temp, write, close) not only user defined callbacks. Many tasks demands hash. Possible giving this feature to users will be useful for them.