After upgrading from build 163 to 164 a corporate upload-site (on the internet) we’re using isn’t working as expected anymore. Smaller uploads (< 1,2MB) are still working but bigger ones (> 2MB) are stalling during upload of some kB of data. Circumventing the ipfire-proxy the upload-site works without any problems.
Problem exists still in actual build 170 - i hoped to get this solveda fter 164, 165, … - that’s why i was waiting until now with my report.
I can’t find anything inside the logs neither in this forum. Don’t know what exactly killed the upload of some more data.
Any hints where to start finding the bug?
So you only experience the problem when you have the web proxy activated and the download is going via it.
I would expect something to show up in the logs.
There is the web proxy system logs on the Logs - System Logs - choose Web Proxy in the drop down box. This will only show anything if the Web Proxy was stopped and restarted for some reason.
In the Logs - Proxy Logs you should have all the accesses via the Proxy. If the download started but then stopped for some reason you should still see an entry in that log. It might be worth un-checking the filter in that log page to be sure you are seeing everything.
I just tried a ~380MB download via the web proxy with CU170 and it completed very quickly with no problems. I found two entries for that operation in my logs.
the problem is during uploading through the proxy to a webside - not while downloading stuff from the internet.
Inside the System-Logs → WebProxy there is no entry shown - like expected. In Log - Proxy Logs i see:
Yes, I misunderstood about the upload vs download.
Is it possible to look at the logs for the corporate site to see if they give any more info as to why the upload starts but then stops after a very small amount.
The web proxy is continuing to try and send stuff to the site so it is not getting back a simple failure message as that would stop the proxy sending anything further.
You mention that it worked with CU163 which would have had version 4.16
Squid was updated to version 5.2 for CU164 and to 5.4.1 for CU165, 5.5 for CU168 and 5.6 for CU169 and version 5.7 is in CU171 that is currently in Testing phase.
I will have a look through the squid change logs and see if I see anything flagged up like this or if a bug has been raised with Squid.
I don’t know how many users of IPFire will do uploads. Most probably use it for caching downloads, however maybe someone else on the forum is also using it for uploads and can comment if they also see the same problem.
This setting “…controls how Squid handles data upload requests from HTTP and FTP agents that require a “Please Continue” control message response to actually send the request body to Squid. It is mostly useful in adaptation environments.”
Default value is Deny, unless rules exist in squid.conf.
Further infos: TYPE: acl_access
And that’s it. I found no further information yet how to implement this. No example, nothing.
Searching the squid source code for forceRequestBodyContinuation I only found some code fragments in /src/FtpServer.cc and /src/Http1Server.cc. Seems to be related.