Mailing List Archive

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

Eric Covener <covener@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED

--- Comment #2 from Eric Covener <covener@gmail.com> ---
I updated the doc and opened a bug for making the opt-in less necessary:
68907

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #3 from Joe Orton <jorton@redhat.com> ---
I think it is quite reasonable that the server has no compulsion to send
Content-Length in HTTP/1.0 responses even if the the CGI script sends them, and
relying on that seems highly dubious.

https://fossil-scm.org/home/file?name=src/http.c&ci=trunk is a naively written
HTTP/1.0 client which does not follow
https://datatracker.ietf.org/doc/html/rfc1945#section-7.2.2 (nearly 30 years
old) in assuming the response body is always delimited by Content-Length

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #4 from Yann Ylavic <ylavic.dev@gmail.com> ---
I agree, for HTTP/1.1 httpd would send "Transfer-Encoding: chunked" but not
here because of the HTTP/1.0 request.

So the only option for httpd is either:
1. bufferize/spool the response to get the full Content-Length before sending
the whole in a one go
2. forward the CGI provided Content-Length and verify that the actual body does
not overflow it (or abort the connection)
3. trust the CGI provided Content-Length (which is SetEnv
"ap_trust_cgilike_cl") and risk response splitting vulns.

And 3. is the simpler and probably the only worth the effort for HTTP/1.0
(IMHO).

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #5 from Yann Ylavic <ylavic.dev@gmail.com> ---
Note: The response without C-L nor T-E provided by httpd when it cannot
determine the body length is what's described in in
https://www.rfc-editor.org/rfc/rfc9112.html#name-message-body-length up to
bullet #8 (last resort..).

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #6 from Richard Hipp <drh@sqlite.org> ---
Thank y'all for your time and analysis. Perhaps I was wrong and it is the
reply that omits Content-Length, not the request as I originally thought. I
see that the Fossil client does not deal well with a missing Content-Length on
the reply - because I know that the CGI sent a Content-Length and it never
occurred to me that the intervening server might suppress the Content-Length.
I'll fix that and see if it resolves the issue.

Sorry for the imprecision in this report - I'm not able to reproduce the
problem locally and am having to go off of field reports.

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #7 from Yann Ylavic <ylavic.dev@gmail.com> ---
Created attachment 39671
--> https://bz.apache.org/bugzilla/attachment.cgi?id=39671&action=edit
Fix Fossil's HTTP protocol handling

I think that Fossil's HTTP protocol handling needs tising here:
https://fossil-scm.org/home/file?ci=trunk&name=src/http.c&ln=664
Something like this patch..

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #8 from Yann Ylavic <ylavic.dev@gmail.com> ---
(sorry fat fingers => s/tising/fixing/)

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #9 from Richard Hipp <drh@sqlite.org> ---
(In reply to Yann Ylavic from comment #7)
>
> I think that Fossil's HTTP protocol handling needs fixing here:
> https://fossil-scm.org/home/file?ci=trunk&name=src/http.c&ln=664

I agree. Thanks for taking the time to look into this. I had already
implemented the patch at <https://fossil-scm.org/home/info/dfefd069b6026eff>
prior to me seeing your post. The patch is on a branch. We are testing it now
to see if that resolves the issue. I'll report back once I know more.

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #10 from Richard Hipp <drh@sqlite.org> ---
Thanks again, everybody.

The problem was indeed in Fossil. Since the Fossil CGI on the server side was
always sending Content-Length in the reply, it was expecting to always get a
Content-Length back on the client side. It never occurred to me that the
intervening web server would elide that header field. Fossil has been updated
at <https://fossil-scm.org/home/info/a8e33fb161f45b65> to resolve this
inadequacy.

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #11 from Yann Ylavic <ylavic.dev@gmail.com> ---
(In reply to Richard Hipp from comment #10)
> https://fossil-scm.org/home/info/a8e33fb161f45b65

FWIW, I think the correct check for the "server did not reply" case is
"iLength<0 && !closeConnection" rather than "iHttpVersion<0", because responses
with no Content-Length nor Transfer-Encoding is allowed only for HTTP/1.1
responses plus "Connection: close" or with HTTP/1.0 responses (where
"Connection: close" is implicit if not specified).
An HTTP/1.1 response with no "Connection: close" defaults to keep-alive so it
might not be wise to accept no C-L nor T-E for those.

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #12 from Richard Hipp <drh@sqlite.org> ---
That is a reasonable suggestion. Thanks. There are other considerations in
play - that same routine is also used to parse raw CGI replies in the case of a
sync via SSH - and so for that reason I have implemented your suggestion
slightly differently, but I think the end result is the same. See the change
at <https://fossil-scm.org/home/info/71919ad1b542832c>.

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #13 from Yann Ylavic <ylavic.dev@gmail.com> ---
Maybe something more explicit like this:
diff --git a/src/http.c b/src/http.c
index 0460e04d1..c71fde995 100644
--- a/src/http.c
+++ b/src/http.c
@@ -676,6 +676,10 @@ int http_exchange(
goto write_err;
}
}
+ if( iLength<0 && !closeConnection ){
+ fossil_warning("\"content-length\" missing from %d keep-alive reply", rc);
+ goto write_err;
+ }
if( rc!=200 ){
fossil_warning("\"location:\" missing from %d redirect reply", rc);
goto write_err;
--

Otherwise in https://fossil-scm.org/home/info/71919ad1b542832c it's possibly
missing an "else" now?

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #14 from Richard Hipp <drh@sqlite.org> ---
Implemented here: <https://fossil-scm.org/home/info/f4ffefe708793b03>

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #15 from Yann Ylavic <ylavic.dev@gmail.com> ---
I don't how the "g.url.isSsh" + Status header protocol works but I get that if
there is no content-length specified then there is also no body to expect, thus
you can keep the connection alive?

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #16 from Richard Hipp <drh@sqlite.org> ---
I think the connections are always "close". But I'm not sure. Better to safe
that hit a problem later.

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #17 from Yann Ylavic <ylavic.dev@gmail.com> ---
It seems that for ssh the connection is not closed finally (unless HTTP/1.0 or
"connection: close"), so the safe way could be to "goto write_err;" for the new
warning?
Reusing a connection without knowing if there is/was a body (and thus ignoring
it) looks a bit hazardous to me, but as I said I don't know how this ssh+status
protocol works..

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org