Re: [PATCH 1/6] gitweb: Separate HTTP header output

From: Junio C Hamano <junkio@cox.net>
Date: Dec 28, 2006, 01:23 UTC
Message-ID: <7v7iwc4xu9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200612272357.56532.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 10 quoted lines

> Always return just after HTTP header is sent when asking only about
> headers (HTTP request method 'HEAD'); first appeared in git_rss.
>
> While at it uniquify style of http_header(...) calls, formerly
> "print $cgi->header(...)", and remove default HTTP status, '200 OK'.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> This one is fairly generic, and if considered worthy, I think
> can be accepted without much ado.

Maybe I am missing something fundamental, but I cannot see how this affects anything whatsoever...

Show 11 quoted lines

> +## functions printing HTTP or HTML: header, footer, error page
> +
> +sub http_header {
> +	my @header = @_;
> +
> +	print $cgi->header(@header);
> +
> +	# Optimization: skip generating the body if client asks only
> +	# for HTTP header (e.g. cache validation).
> +	return if ($cgi->request_method() eq 'HEAD');
> +}

Ok, so this explicitly written "return" returns when it is a HEAD request not GET. Otherwise the control falls out of the end of the function. Either way you return undef.

Then the caller does...

Show 14 quoted lines

> @@ -1709,8 +1719,11 @@ sub git_header_html {
>  	} else {
>  		$content_type = 'text/html';
>  	}
> -	print $cgi->header(-type=>$content_type, -charset => 'utf-8',
> -	                   -status=> $status, -expires => $expires);
> +	http_header(
> +		-type => $content_type,
> +		-charset => 'utf-8',
> +		-status => $status,
> +		-expires => $expires);
>  	print <<EOF;
>  <?xml version="1.0" encoding="utf-8"?>
>  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

which means it does not omit generating the body anyway no matter what "sub http_header" did...

Or is there some Perl magic that makes a return from sub named *_header magically terminate the execution of the caller?

Puzzled...