git-commit-vandalism/t/lib-httpd/error.sh

#!/bin/sh

printf "Status: 500 Intentional Breakage\n"

printf "Content-Type: "
charset=iso-8859-1
case "$PATH_INFO" in
*html*)
	printf "text/html"
	;;
*text*)
	printf "text/plain"
	;;
*charset*)
	printf "text/plain; charset=utf-8"
	charset=utf-8
	;;
*utf16*)
	printf "text/plain; charset=utf-16"
	charset=utf-16
	;;
*odd-spacing*)
	printf "text/plain; foo=bar ;charset=utf-16; other=nonsense"
	charset=utf-16
	;;
esac
printf "\n"

printf "\n"
printf "this is the error message\n" |
iconv -f us-ascii -t $charset
t5550: test display of remote http error messages Since commit 426e70d (remote-curl: show server content on http errors, 2013-04-05), we relay any text/plain error messages from the remote server to the user. However, we never tested it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-05-22 11:29:03 +02:00			`#!/bin/sh`

			`printf "Status: 500 Intentional Breakage\n"`

			`printf "Content-Type: "`
http: extract type/subtype portion of content-type When we get a content-type from curl, we get the whole header line, including any parameters, and without any normalization (like downcasing or whitespace) applied. If we later try to match it with strcmp() or even strcasecmp(), we may get false negatives. This could cause two visible behaviors: 1. We might fail to recognize a smart-http server by its content-type. 2. We might fail to relay text/plain error messages to users (especially if they contain a charset parameter). This patch teaches the http code to extract and normalize just the type/subtype portion of the string. This is technically passing out less information to the callers, who can no longer see the parameters. But none of the current callers cares, and a future patch will add back an easier-to-use method for accessing those parameters. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-05-22 11:29:47 +02:00			`charset=iso-8859-1`
t5550: test display of remote http error messages Since commit 426e70d (remote-curl: show server content on http errors, 2013-04-05), we relay any text/plain error messages from the remote server to the user. However, we never tested it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-05-22 11:29:03 +02:00			`case "$PATH_INFO" in`
			`html)`
			`printf "text/html"`
			`;;`
			`text)`
			`printf "text/plain"`
			`;;`
http: extract type/subtype portion of content-type When we get a content-type from curl, we get the whole header line, including any parameters, and without any normalization (like downcasing or whitespace) applied. If we later try to match it with strcmp() or even strcasecmp(), we may get false negatives. This could cause two visible behaviors: 1. We might fail to recognize a smart-http server by its content-type. 2. We might fail to relay text/plain error messages to users (especially if they contain a charset parameter). This patch teaches the http code to extract and normalize just the type/subtype portion of the string. This is technically passing out less information to the callers, who can no longer see the parameters. But none of the current callers cares, and a future patch will add back an easier-to-use method for accessing those parameters. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-05-22 11:29:47 +02:00			`charset)`
			`printf "text/plain; charset=utf-8"`
			`charset=utf-8`
			`;;`
remote-curl: reencode http error messages We currently recognize an error message with a content-type "text/plain; charset=utf-16" as text, but we ignore the charset parameter entirely. Let's encode it to log_output_encoding, which is presumably something the user's terminal can handle. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-05-22 11:30:29 +02:00			`utf16)`
			`printf "text/plain; charset=utf-16"`
			`charset=utf-16`
			`;;`
http: fix charset detection of extract_content_type() extract_content_type() could not extract a charset parameter if the parameter is not the first one and there is a whitespace and a following semicolon just before the parameter. For example: text/plain; format=fixed ;charset=utf-8 And it also could not handle correctly some other cases, such as: text/plain; charset=utf-8; format=fixed text/plain; some-param="a long value with ;semicolons;"; charset=utf-8 Thanks-to: Jeff King <peff@peff.net> Signed-off-by: Yi EungJun <eungjun.yi@navercorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-06-18 00:11:53 +02:00			`odd-spacing)`
			`printf "text/plain; foo=bar ;charset=utf-16; other=nonsense"`
			`charset=utf-16`
			`;;`
t5550: test display of remote http error messages Since commit 426e70d (remote-curl: show server content on http errors, 2013-04-05), we relay any text/plain error messages from the remote server to the user. However, we never tested it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-05-22 11:29:03 +02:00			`esac`
			`printf "\n"`

			`printf "\n"`
http: extract type/subtype portion of content-type When we get a content-type from curl, we get the whole header line, including any parameters, and without any normalization (like downcasing or whitespace) applied. If we later try to match it with strcmp() or even strcasecmp(), we may get false negatives. This could cause two visible behaviors: 1. We might fail to recognize a smart-http server by its content-type. 2. We might fail to relay text/plain error messages to users (especially if they contain a charset parameter). This patch teaches the http code to extract and normalize just the type/subtype portion of the string. This is technically passing out less information to the callers, who can no longer see the parameters. But none of the current callers cares, and a future patch will add back an easier-to-use method for accessing those parameters. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-05-22 11:29:47 +02:00			`printf "this is the error message\n" \|`
			`iconv -f us-ascii -t $charset`