Forum OpenACS Development: Re: http POST X binary file

Collapse
Posted by Iuri Sampaio on
Good news!

Restarting Naviserver did the magic trick!

I believe there was some sort of cache, which was holding "Content-type" "application/x-www-form-urlencoded in the header. No idea.

So, The solution was: wrapping up the request POST (i.e. ns_http) within an ad_proc, which puts that action out of ad_form's context, then it cleans up NS headers.

Thanks, Gustaf, for triggering this enlightenment.

Best wishes,
I

Collapse
Posted by Gustaf Neumann on
Iuri, to save your time: neither in NaviServer or in OpenACS is something i would call "cache"; and if your code works after the restart, it must have different causes to be found in your code, but not in the infrastructure.

Certainly, ns_sets (which are used for header fields) can be reused within a request for multiple usages/purposes. After a request, these are cleaned up automatically via "ns_set cleanup". So, if you use/reuse e.g. an ns_set for headers for multiple "ns_http" client requests, and you are always adding additional fields to it, you might end up with a request with multiple "content-type" header fields. So, the general recommendation is to use always fresh ns_sets for http-client requests (unless you know, what you do).

Collapse
Posted by Iuri Sampaio on
Gustaf,
I have no idea what possible be causing this strange behavior in my installation.

I've upgraded to NaviServer/4.99.19 (tar-4.99.19) and acs-kernel-5.10.0d30. last week. Plus it's a fresh install. So it's too recent to get myself "forking around" anything in the core 😊

It could be NGINX cache. However, it happened only in this instance, among others, which are served by the same proxy.

Anyway, all it means is that I need more time to dig further into this problem and find the actual cause of it.

Best wishes,
I

Collapse
Posted by Gustaf Neumann on
You don't have to dig deeper, but just in your own code. That was the good news.