I just tried WordPress again on Firefox and Chrome. No problems.
Is there an obj folder? If so, maybe try to do 'make clean'
after step 5.
On 2021-05-20 16:02, Steve Williams wrote:
> Hi,
>
>
> I still get a connection error from my Andriod Nextcloud client and Wordpress
> does not work correctly on Firefox.
>
> Please see my steps below to ensure I have tested the correct thing.
> (patches are attached as well).
>
> Nextcloud and roundcubemail on Firefox work fine.
>
> On Chrome, everything works as expected.
>
> Just to make sure I did this correctly:
>
> 1. Extract clean 6.9 httpd source from 6.9/src.tar.gz
> 2. Apply patch (p1) from May 15 email from Florian with subject
> (Re: httpd(8): don't try to chunk-encode an empty body)
> 3. Apply patch (p2) from start of this email thread (httpd(8):
> fastcgi & Content-Length: 0)
> 4. Apply patch (p3) from this email thread (Matthias)
> 5. All patches applied cleanly
> 6. make
> 7. make install
> restart and test
>
>
>
>
> pcengine# patch < ../p1
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |k--- httpd.h
> |+++ httpd.h
> --------------------------
> Patching file httpd.h using Plan A...
> Hunk #1 succeeded at 300.
> Hmm... The next patch looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |diff --git server_fcgi.c server_fcgi.c
> |index 64a0e9d2abb..e1e9704c920 100644
> |--- server_fcgi.c
> |+++ server_fcgi.c
> --------------------------
> Patching file server_fcgi.c using Plan A...
> Hunk #1 succeeded at 114.
> Hunk #2 succeeded at 545.
> Hunk #3 succeeded at 599.
> Hunk #4 succeeded at 616.
> done
> pcengine# patch < ../p2
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |--- server_fcgi.c
> |+++ server_fcgi.c
> --------------------------
> Patching file server_fcgi.c using Plan A...
> Hunk #1 succeeded at 636.
> done
> pcengine# patch < ../p3
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |--- usr.sbin/httpd/server_fcgi.c Thu May 20 05:57:23 2021
> |+++ usr.sbin/httpd/server_fcgi.c Thu May 20 06:03:40 2021
> --------------------------
> Patching file server_fcgi.c using Plan A...
> Hunk #1 succeeded at 620.
> Hunk #2 succeeded at 642.
> done
>
> On 19/05/2021 11:41 p.m., Florian Obser wrote:
>> Yes, ugh, this is much better, thanks!
>> I'll wait for Steve to confirm that it fixes nextclown for him, too and
>> then I'll put it in.
>>
>> On 2021-05-20 06:43 +02, Matthias Pressfreund <m...@fn.de> wrote:
>>> Fix works for me, too. Thanks.
>>>
>>> It now sets the "Content-Length: 0" header for ALL traffic that
>>> is not chunk-encoded. But chunk-encoding may be disabled already
>>> (e.g. for http/1.0). I'd therefore suggest to move the fix to where
>>> the handling of zero-length bodies actually takes place.
>>>
>>>
>>> --- usr.sbin/httpd/server_fcgi.c Thu May 20 05:57:23 2021
>>> +++ usr.sbin/httpd/server_fcgi.c Thu May 20 06:03:40 2021
>>> @@ -620,6 +620,12 @@
>>> EVBUFFER_LENGTH(clt->clt_srvevb) == 0) {
>>> /* Can't chunk encode an empty body. */
>>> clt->clt_fcgi.chunked = 0;
>>> + key.kv_key = "Content-Length";
>>> + if ((kv = kv_find(&resp->http_headers, &key)) == NULL) {
>>> + if (kv_add(&resp->http_headers,
>>> + "Content-Length", "0") == NULL)
>>> + return (-1);
>>> + }
>>> }
>>> /* Set chunked encoding */
>>> @@ -636,13 +642,6 @@
>>> if (kv_add(&resp->http_headers,
>>> "Transfer-Encoding", "chunked") == NULL)
>>> return (-1);
>>> - } else {
>>> - key.kv_key = "Content-Length";
>>> - if ((kv = kv_find(&resp->http_headers, &key)) == NULL) {
>>> - if (kv_add(&resp->http_headers,
>>> - "Content-Length", "0") == NULL)
>>> - return (-1);
>>> - }
>>> }
>>> /* Is it a persistent connection? */
>>>
>>>
>>> On 2021-05-19 20:44, Florian Obser wrote:
>>>> The whole point of using Transfer-Encoding: chunked for fastcgi was so
>>>> that we do not need to provide a Content-Length header if upstream
>>>> doesn't give us one. (We'd need to slurp in all the data ugh).
>>>>
>>>> Now turns out that if we disable chunked encoding for zero sized bodies
>>>> some browsers are picky and want a Content-Length: 0 (Firefox, Safari)
>>>> or they'll just sit there and wait for the connection to close.
>>>>
>>>> Problem reported by Matthias Pressfreund with wordpress.
>>>> Debugged with the help of weerd@ who pointed out that the problem is
>>>> actually browser dependent. From there it was pretty clear what the
>>>> problem was.
>>>>
>>>> OK?
>>>>
>>>> diff --git server_fcgi.c server_fcgi.c
>>>> index 31d7322e9f7..b9dc4f6fe04 100644
>>>> --- server_fcgi.c
>>>> +++ server_fcgi.c
>>>> @@ -636,6 +636,13 @@ server_fcgi_header(struct client *clt, unsigned int
>>>> code)
>>>> if (kv_add(&resp->http_headers,
>>>> "Transfer-Encoding", "chunked") == NULL)
>>>> return (-1);
>>>> + } else {
>>>> + key.kv_key = "Content-Length";
>>>> + if ((kv = kv_find(&resp->http_headers, &key)) == NULL) {
>>>> + if (kv_add(&resp->http_headers,
>>>> + "Content-Length", "0") == NULL)
>>>> + return (-1);
>>>> + }
>>>> }
>>>> /* Is it a persistent connection? */
>>>>
>
