Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Perl - HEAD, GET & POST still replacing original files?' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Perl - HEAD, GET & POST still replacing original files?
Authored by: TvE on Nov 15, '03 06:19:49AM
There have been previous discussions about installing GET, HEAD and POST (a part of the LWP installation) will owerwrite som existing header files (though I am not quite sure WHAT the original header files are for - maybe a programmer can clear this up for me?)

Do you want to install the GET alias? no
Do you want to install the HEAD alias? no
Do you want to install the POST alias? no


I notice you DON'T install these files ;-)


- What will be missing from the LWP installation due to that choice?

- TvE

[ Reply to This | # ]
Perl - HEAD, GET & POST still replacing original files?
Authored by: blakers on Nov 15, '03 11:16:26AM

here's a thread with comments/explanations you may find helpful:

http://www.mail-archive.com/macosx@perl.org/msg05375.html



[ Reply to This | # ]
Perl - HEAD, GET & POST still replacing original files?
Authored by: babbage on Nov 17, '03 02:22:41AM

There's nothing terribly complicated about it. The system's "head" command is a tool for retrieving the first few lines from a stream of data -- such as a file. So for example if I had a file with the contents of Charles Dickens' "A Tale of Two Cities" as plain texe, then running head dickents_atotc.txt at a command prompt would dump out the first 10 lines from the book. Nothing complicated there -- it's just a convenience tool.

On the other hand, Perl's LWP library for writing programs that talk to web servers includes a tool that will send HTTP "HEAD" requests. This one is a bit more obscure, but isn't very complicated. Web servers are just programs that understand & can respond to the HTTP "language", which consists of a dozen or so commands. The two most common & well known HTTP commands are "GET" and "POST" -- if you've written any HTML forms, this is what's being called in those <form action="GET" method="/cgi-bin/foo.pl"> lines. GET just means "I would like to retrieve a certain document from your web server", while POST means "I am going to upload a document to your web server, and will listen to whatever your response comes back in return." Nothing very complicated there; the vast majority of web traffic is just these two commands (almost every time you click on a link, your browser is running in the background saying "I would like to GET so-and-so" to some remove web server).

The HTTP "HEAD" command is another part of the HTTP vocabulary. Rather than retrieving a document itself though, it asks for information about that document & about the server that is processing the request. For example, the lynx text-mode web browser provides a tool for making HEAD requests:

% lynx -dump -head http://www.macosxhints.com/
HTTP/1.1 200 OK
Date: Mon, 17 Nov 2003 07:04:11 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) mod_fastcgi/2.2.10 mod_jk/1.2.0 D
AV/1.0.3 mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.12 OpenSSL/0.9.
6b
X-Powered-By: PHP/4.2.2
Set-Cookie: LastVisit=1069052651; expires=Tue, 16-Nov-04 07:04:11 GMT; path=/; 
domain=macosxhints.com
Set-Cookie: LastVisitTemp=deleted; expires=Sun, 17-Nov-02 07:04:10 GMT; path=/;
 domain=macosxhints.com
Connection: close
Content-Type: text/html

Most of the time, your web browser just handles this information for you without having to get your feedback on the matter. Sometimes however it can be useful or just educational to make one of these requests manually. Maybe you're just curious what software a given site is running (in this case, it seems to be Apache, with support for PHP, Perl, and encryption). Maybe you want to examine the cookies that are being set for debugging web development work, or you just want to check that a site that won't load in your browser can at least be reached by some other means (hey, it happens -- browser caches can be annoying things).

+++++

The problem here is that Perl's LWP's HEAD request tool is installed by default at /usr/bin/HEAD, next to the system provided /usr/bin/head "start of data" tool. On Linux, *BSD, or most other varieties of Unix, this is no big deal, because the case-sensitive nature of the file systems these run on mean that HEAD, head, Head, and hEaD are four completely different names (and the fact that they look alike is irrelevant at this level). On the Mac though, the filesystem is typically HFS+, and HFS+ sees no difference between HEAD and head. As a result, when LWP installs the web request tool at /usr/bin/HEAD, it ends up clobbering the file processing tool that had been at /usr/bin/head.

There are long, complicated, and more or less reasonable reasons why the LWP folks don't see any problem here, and so haven't felt a need to "fix" the situation on their end. Apple hasn't (yet) had time to come up with a filesystem that would behave more like other Unix filesystems (and arguably, they don't want to -- HFS+ can be seen as less confusing to many users who aren't used to thinking of case sensitivity issues). So we're at an impasse -- OSX has been out for a few years now, and the long-standing advice for anyone that wants to do any web programming in Perl (or just to install anything that in turn needs that capability -- it comes up surprisingly often) is to just say 'no' when asked whether to install these shortcuts. It's not a totally bad solution -- if you don't know what the tools are, you may not ever need them -- but hopefully there will be a friendlier way to deal with this some day.

---
--
DO NOT LEAVE IT IS NOT REAL

[ Reply to This | # ]