Alois Mahdal's questions

In Apache2 documentation thay say that in <VirtualHost *:80>, the * can be replaced by IP or FQDN, but the FQDN is not recommended.

Addr can be:

• The IP address of the virtual host;
• A fully qualified domain name for the IP address of the virtual host (not recommended);

But why is it not recommended? If I have www.mydomain.com and webmail.mydomain.com pointing to the same IP address, why shouldn't I use the names here?

I have a trivial CGI script that outputs simple text content. It's written in Perl and using CGI module and it specifies only the most basic headers:

print $q->header(
    -type               => 'text/plain',
    -Content_length     => $length,
);
print $stuff;

There's no apparent issue with functionality—neither User Agent nor server do complain a bit, but I'm confused about the fact that Wireshark does not recognize the HTTP response as HTTP—it's marked as TCP.

Here is request and response, as shown in "Follow TCP Stream" dialog box:

GET /cgi-bin/memfile/memfile.pl?mbytes=1 HTTP/1.1
Host: 10.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: cs,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Date: Thu, 05 Apr 2012 18:52:23 GMT
Server: Apache/2.2.15 (Win32) mod_ssl/2.2.15 OpenSSL/0.9.8m
Content-length: 1048616
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/plain; charset=ISO-8859-1

XXXXXXXX...

And here is the packet overview)

No.     Time        Source      srcp   Destination  dstp    Protocol    Info                                tcp.stream  abstime
5       0.112749    10.0.0.1    80     10.0.0.2     48072   TCP         [TCP segment of a reassembled PDU]  0           20:52:23.228063

Frame 5: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
Ethernet II, Src: 00:12:34:56:78:9a, Dst: 00:12:34:56:78:9b
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.2 (10.0.0.2)
Transmission Control Protocol, Src Port: http (80), Dst Port: 48072 (48072), Seq: 1, Ack: 330, Len: 1460

Now when I open the stream in Wireshark:

• first three packets are usual TCP handshake
• fourth packet the GET request shown as HTTP with this in "Info" field GET /cgi-bin/memfile/memfile.pl, as I expect
• fifth packet contains the response, but is not marked as an HTTP response. I would expect Info field to be something like "HTTP 200 OK", but there's only a generic "[TCP segment of a reassembled PDU]". The real inconvenience is that this packet is not caught by "http.response" filter

Can somebody explain why Wireshark does not recognize HTTP nature of the fifth packet? Is there something wrong with the response?

I have a Windows 7 amd64 box where one directory is shared:

• local path is d:\drop\
• remote path is \\aloism\drop
• from SMB point of view, Everyone has Read and Write permission
• ACLs for the folder are set so that all authenticated users have read and write permissions:
  NT AUTHORITY\Authenticated Users:(OI)(CI)C (which is inherited to all levels below)

Now I create a symbolic link within the structure of the directory:

D:\drop>mklink /d tools2 tools
symbolic link created for tools2 <<===>> tools

The problem is that I can't access this new directory from any of the remote machines (a Windows 7 box and a Windows XP box—both behave the same way):

C:\>dir  \\aloism\drop\tools2\
Volume in drive \\aloism\drop is droot
Volume Serial Number is FA73-1897

Directory of \\aloism\drop\tools2

File Not Found

How can I make it work? Possibly also for files?

RFC822 on Return-Path::

This field is added by the final transport system that delivers the message to its recipient. The field is intended to contain definitive information about the address and route back to the message's originator.

So how come some e-mails have two of them? (In my sample, usually one at the end and one at the start, from which I assume that client added it there.) Isn't there only one originator?

Is that a bad habit of some clients?

I have a seemingly easy task, but somehow I just can't get it to work:

Some interesting lines from my httpd.conf:

...
DocumentRoot "D:/opt/apache/htdocs"
...
ScriptAlias /cgi-bin/ "D:/opt/apache/cgi-bin/"
...
<Directory "D:/opt/apache/htdocs">
   Options Indexes FollowSymLinks ExecCGI
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>
<Directory "D:/opt/apache/cgi-bin/">
    AllowOverride None
    Options ExecCGI
    Order allow,deny
    Allow from all
</Directory>

(I know it's dumb but it's only a testing machine :D.)

Now, I have d:\opt\apache\cgi-bin\expired.pl and I expect GET /licensecheck.php?code=123456. And I wish to fake client into thinking it speaks with /licensecheck.php, but actually return data by \expired.pl.

What I tried was setting following at the end of http.conf:

RewriteEngine on
RewriteRule ^/licensecheck.php$ /cgi-bin/expired.pl [T=application/x-httpd-cgi,L]

...but it keeps 404-ing me, looking for cgi-bin directory (not cgi-bin\expired.pl) in my DocumentRoot!

[error] [client 127.0.0.1] script not found or unable to stat: D:/opt/apache/htdocs/cgi-bin

• /cgi-bin/expired.pl and all other scripts in /cgi-bin/ work as expected,

• Only way I could make it work was actually putting the \expired.pl to DocumentRoot, but I don't want this, I want my cgi-bin neatly separated :)