From: Eric Sunshine <sunshine@sunshineco.com>
To: Max Kirillov <max@max630.net>
Cc: Jeff King <peff@peff.net>,
Florian Manschwetus <manschwetus@cs-software-gmbh.de>,
Chris Packham <judge.packham@gmail.com>,
Konstantin Khomoutov <kostix+git@007spb.ru>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875
Date: Sat, 25 Nov 2017 19:38:33 -0500 [thread overview]
Message-ID: <CAPig+cRRHepuNNva_cq2YPEDSBCO25y1mihuC52RntpJ+a+YMg@mail.gmail.com> (raw)
In-Reply-To: <20171125214721.GA26158@jessie.local>
On Sat, Nov 25, 2017 at 4:47 PM, Max Kirillov <max@max630.net> wrote:
> Thanks for the review. I saw only reaction of the Jeff in
> the original thread and though that it is ok otherwise. I'm
> fixing the things you mentioned.
The commentary (in which you talked about restoring the patch and
squashing) seemed to imply that this had been posted somewhere before,
but it wasn't marked as "v2" (or whatever attempt) and lacked a URL
pointing at the previous attempt, so it was difficult to judge.
> On Thu, Nov 23, 2017 at 08:30:39PM -0500, Eric Sunshine wrote:
>>> +static ssize_t read_request_fix_len(int fd, size_t req_len, unsigned char **out)
>>
>> Wrong data type: s/size_t req_len/ssize_t req_len/
>
> Passing negative value to the function makes no sense. I
> could add explicit type cast to make it clear. It should be
> safe as site_t's range is bigger, and overflown
> CONTENT_LENGTH results in die() at parsing (I have a test
> which verifies it)
A concern with requesting size_t bytes is that, if it does read all
bytes, that value can't necessarily be represented by the ssize_t
returned from the function. Where would the cast be placed that you
suggest? How do other git functions deal with this sort of situation?
next prev parent reply other threads:[~2017-11-26 0:38 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 10:38 [PATCH] Fix http-backend reading till EOF, ignoring CONTENT_LENGTH, violating rfc3875 -- WAS: Problem with git-http-backend.exe as iis cgi Florian Manschwetus
2016-03-29 20:13 ` Jeff King
2016-03-30 9:08 ` AW: " Florian Manschwetus
2016-04-01 23:55 ` Jeff King
2017-11-23 23:45 ` [PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov
2017-11-24 1:30 ` Eric Sunshine
2017-11-25 21:47 ` Max Kirillov
2017-11-26 0:38 ` Eric Sunshine [this message]
2017-11-26 0:43 ` Max Kirillov
2017-11-24 5:54 ` Junio C Hamano
2017-11-24 8:30 ` AW: " Florian Manschwetus
2017-11-26 1:50 ` Max Kirillov
2017-11-26 1:47 ` [PATCH v4 0/2] " Max Kirillov
2017-11-26 1:47 ` [PATCH v4 1/2] " Max Kirillov
2017-11-26 1:47 ` [PATCH v4 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases Max Kirillov
2017-11-26 1:54 ` [PATCH v5 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov
2017-11-26 1:54 ` [PATCH v5 1/2] " Max Kirillov
2017-11-26 3:46 ` Junio C Hamano
2017-11-26 8:13 ` Max Kirillov
2017-11-26 9:38 ` Junio C Hamano
2017-11-26 19:39 ` Max Kirillov
2017-11-26 1:54 ` [PATCH v5 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases Max Kirillov
2017-11-26 19:38 ` [PATCH v6 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov
2017-11-26 19:38 ` [PATCH v6 1/2] " Max Kirillov
2017-11-26 22:08 ` Eric Sunshine
2017-11-29 3:22 ` Jeff King
2017-12-03 1:02 ` Junio C Hamano
2017-12-03 2:49 ` Jeff King
2017-12-03 6:07 ` Junio C Hamano
2017-12-04 7:18 ` AW: " Florian Manschwetus
2017-12-04 17:13 ` Jeff King
2017-11-26 19:38 ` [PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases Max Kirillov
2017-11-26 22:18 ` Eric Sunshine
2017-11-26 22:40 ` Max Kirillov
2017-11-29 3:26 ` Jeff King
2017-11-29 5:19 ` Max Kirillov
2017-12-03 0:46 ` Junio C Hamano
2017-11-27 0:29 ` Junio C Hamano
2017-11-27 4:02 ` [PATCH v6 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Junio C Hamano
2017-11-29 5:07 ` Max Kirillov
2017-12-03 0:48 ` Junio C Hamano
2017-12-12 16:17 ` Need to add test artifacts to .gitignore Dan Jacques
2017-12-12 19:00 ` [RFC PATCH] t/helper: Move sources to t/helper-src; gitignore any files in t/helper Stefan Beller
2017-12-12 19:59 ` Junio C Hamano
2017-12-12 20:56 ` [PATCH] t/helper: ignore everything but sources Stefan Beller
2017-12-12 21:06 ` Junio C Hamano
2017-12-13 20:12 ` Stefan Beller
2017-12-12 21:06 ` Todd Zullinger
2017-12-19 22:13 ` [PATCH v6 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Junio C Hamano
2017-12-20 4:30 ` Max Kirillov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPig+cRRHepuNNva_cq2YPEDSBCO25y1mihuC52RntpJ+a+YMg@mail.gmail.com \
--to=sunshine@sunshineco.com \
--cc=git@vger.kernel.org \
--cc=judge.packham@gmail.com \
--cc=kostix+git@007spb.ru \
--cc=manschwetus@cs-software-gmbh.de \
--cc=max@max630.net \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).