On Wed, Feb 06, 2013 at 07:56:08AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Is it worth having a strbuf_set* family of functions to match the
> > strbuf_add*? We seem to have these sorts of errors with strbuf from time
> > to time, and I wonder if that would make it easier (and mor
Jeff King writes:
> Is it worth having a strbuf_set* family of functions to match the
> strbuf_add*? We seem to have these sorts of errors with strbuf from time
> to time, and I wonder if that would make it easier (and more readable)
> to do the right thing.
Possibly.
The callsite below may be
On Wed, Feb 06, 2013 at 11:24:41AM +0100, Michael Schubert wrote:
> On 01/31/2013 11:09 PM, Junio C Hamano wrote:
>
> >
> > -static int http_request_reauth(const char *url, void *result, int target,
> > +static int http_request_reauth(const char *url,
> > + struct strbu
On 01/31/2013 11:09 PM, Junio C Hamano wrote:
>
> -static int http_request_reauth(const char *url, void *result, int target,
> +static int http_request_reauth(const char *url,
> +struct strbuf *type,
> +void *result, int target,
>
Shawn Pearce writes:
> Looks fine to me too, but I think the test won't work now. :-)
Heh, that's amusing ;-)
t/t5551-http-fetch.sh | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index cb95b95..47eb769 100755
--- a/t/t5551-ht
On Mon, Feb 4, 2013 at 12:38 AM, Jeff King wrote:
> On Sun, Feb 03, 2013 at 11:17:33PM -0800, Junio C Hamano wrote:
>
> > Does this look good to both of you (relative to Shawn's patch)?
> >
> > remote-curl.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/re
On Sun, Feb 03, 2013 at 11:17:33PM -0800, Junio C Hamano wrote:
> Does this look good to both of you (relative to Shawn's patch)?
>
> remote-curl.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/remote-curl.c b/remote-curl.c
> index e6f3b63..933c69a 100644
> --
Jeff King writes:
> I was specifically thinking of this (on top of your patch):
>
> diff --git a/remote-curl.c b/remote-curl.c
> index e6f3b63..63680a8 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -134,14 +134,12 @@ static struct discovery* discover_refs(const char
> *service)
>
On Fri, Feb 01, 2013 at 10:09:26AM -0800, Junio C Hamano wrote:
> > so I do not think the patch makes anything worse. However, should we
> > take this opportunity to make the "did we get a smart response" test
> > more robust? That is, should we actually be checking the content-type
> > in the out
Jeff King writes:
> Should this be "From:" Shawn? The tone of the message and the S-O-B
> order makes it look like it.
Yes. I should have left that line when edited the format-patch
output in my MUA to say I was resending something that vger rejected
and people did not see after tweaking the pat
On Thu, Jan 31, 2013 at 02:09:40PM -0800, Junio C Hamano wrote:
> Before parsing a suspected smart-HTTP response verify the returned
> Content-Type matches the standard. This protects a client from
> attempting to process a payload that smells like a smart-HTTP
> server response.
>
> JGit has bee
On Thu, Jan 31, 2013 at 1:59 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> Before parsing a suspected smart-HTTP response verify the returned
>> Content-Type matches the standard. This protects a client from
>> attempting to process a payload that smells like a smart-HTTP
>> server respon
Before parsing a suspected smart-HTTP response verify the returned
Content-Type matches the standard. This protects a client from
attempting to process a payload that smells like a smart-HTTP
server response.
JGit has been doing this check on all responses since the dawn of
time. I mistakenly fail
13 matches
Mail list logo
