http://www.perlmonks.org?node_id=205205

gryphon has asked for the wisdom of the Perl Monks concerning the following question:

Greetings fellow monks,

I have a slightly interesting but extremely annoying problem: I've recently built a fairly complex Web application service for a gigantic Redmond, Washington based software company (refered to hereafter as GRWBSC). I've used various open source technologies for this service including Perl (of course), Apache, Linux, and MySQL. Upon completion, the client from GRWBSC was extremely pleased with the service.

The problem started when said client from GRWBSC had her boss look at said Web service. This boss used netcraft.com to figure out our technology choices. This boss then became extremely upset. I must now recode the entire service using GRWBSC-only technology. I'd rather not.

I figure that netcraft.com is using the "Server" line from an HTTP header to determine the server software I'm using. So my thought is: perhaps I just muck aroung with the HTTP header and call it good.

my $cgi = new CGI; print $cgi->header( -server => 'Microsoft-IIS/6.0', -server_software => 'Microsoft-IIS/6.0', -cache_control => 'private', -content_length => '31000' );

OK, this seems to work for "Server-software", but not for the actual "Server" line. It apparently gets overridden by Apache. Anyone have any suggestions for me? I'd be really annoyed if I had to recode this whole thing (2 months worth of work) in ASP, MSSQL, etc. Thanks.

gryphon
code('Perl') || die;

Replies are listed 'Best First'.
Re: Altering "Server" HTTP Header Param
by dws (Chancellor) on Oct 15, 2002 at 00:03 UTC
    I figure that netcraft.com is using the "Server" line from an HTTP header to determine the server software I'm using. So my thought is: perhaps I just muck aroung with the HTTP header and call it good.

    gryphon, the situation you're in sucks, but it's a business problem, not a technical one. The "let's just fake it" approach is really tempting, but it could expose your company to legal problems. The customer might be unhappy with your technology choices now, but I would expect them to be furious if they were to discover that you were intentionally deceiving them. Check with your legal people before you deploy a configuration that lies about what the underlying platform is (even if your customer has been caught pulling the same trick before).

    When letting the contract, if your customer didn't specify constraints on technology (i.e., they didn't say "you must use ours"), then coming back to your company with an additional constraint at a late date should trigger a business-level renegotiation. They're asking you to build something else, after all.

    Don't risk getting your company, and yourself, in a lot of hot water.

Re: Altering "Server" HTTP Header Param
by gryphon (Abbot) on Oct 14, 2002 at 21:59 UTC

    Greetings all,

    tye had a really interesting idea he told me via Chatterbox. He said I should try making the script a non-parsed headers script and feed in my own HTTP headers manually. I did so, and now all my HTTP headers appear to be "correct" (i.e. incorrect intentionally).

    Problem is, it doesn't appear to work when I try this using CGI.pm, but only as a flat series of lines.

    #!/usr/bin/perl use strict; use warnings; =pod use CGI; my $cgi = new CGI; print $cgi->header( -nph => 1, -type => 'text/html; charset=ISO-8859-1', -cache_control => 'private', -connection => 'close', -server => 'Microsoft-IIS/6.0' ); =cut print <<ENDOFHTML; HTTP/1.1 200 OK Cache-Control: private Date: Mon, 14 Oct 2002 21:41:25 GMT Server: Microsoft-IIS/6.0 Content-Length: 31000 Content-Type: text/html Expires: Mon, 25 Oct 2010 21:21:21 GMT P3P: CP='ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo +OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI' <HTML><HEAD><!-- the rest of the html document -->

    The problem is that NetCraft is still reporting me running Apache. However, after some reading on their site, I get the feeling (backed by no real evidence) that they query for new site data on a daily basis. So perhaps by tomorrow, my problems will be solved.

    gryphon
    code('Perl') || die;

      As a faster means to confirming your headers and all the other data transferred during an HTTP session, try using Ethereal. It's a packet-sniffer; it's been ported to several platforms, and has some very cool abilities. After capturing an HTTP session or two, you can scroll through all the sniffed packets and get a blow-by-blow analysis of the session including (you guessed it) headers sent by the browser and headers sent by the server, as well as document text. Much faster than waiting for Netcraft to recrawl your server.

      I discovered Ethereal over this weekend, and it's now an essential tool in my toolbox. I'll be using it for my own CGI programming. Definitely. Find it here.

      Good luck on satisfying your client.

      -Shawn / (Ph) Phaysis
      If idle hands are the tools of the devil, are idol tools the hands of god?

      You should be able to get that to work, but it may not fool Netcraft. For one thing, they report operating system based analysis of TCP/IP traffic. You would also have to have enough control over that server to make sure that every call to "/" will run your script. Without a dedicated server, you probably don't have that.
Re: Altering "Server" HTTP Header Param
by blakem (Monsignor) on Oct 14, 2002 at 20:59 UTC
    I think you'll have to tweak the apache source and recompile. The relevant file is src/main/http_main.c. Grep for 'server_version' and 'SERVER_BASEVERSION' to find the lines that deal with setting the server name.

    The logic to create that value has gotten more complex since I looked at it ages ago, so it will take some work to figure out exactly how it gets set.

    -Blake

      Greetings blakem,

      Yeah, I noticed that. Unfortunately, I can't recompile Apache since this all lives in an account on an ISP. I'm hoping that I can either find a Perl solution to force the "Server" header change, or use an ".htaccess" file to do something for me.

      I'm getting discouraged, though. I think I'm screwed.

      gryphon
      code('Perl') || die;

        To actually change the server tokens you need to recompile, but you can turn them off with the ServerTokens directive.

        Unfortunately, “[the] setting[s] appl[y] to the entire server, and cannot be enabled or disabled on a virtualhost-by-virtualhost basis.” Which means it must be used in the main server configuration files. Some ISPs can be convinced to turn them off completely on a security basis — other than that you’re out of luck.

        I'm afraid you are screwed if you can't recompile Apache. There is no other way to do it.
Re: Altering "Server" HTTP Header Param
by Flexx (Pilgrim) on Oct 15, 2002 at 01:30 UTC

    Somehow I had to giggle when I read your post... That's what comes from sleeping with the enemy. Weren't you courious when they asked you to sign the papers with blood? ;)

    However, I'd have serious legal concerns about trying to deceive your client. What you try to do is, indeed, fraud. If they want you to port this to some other platform/system/language, you can't just pretend you do it. Do it, or leave it (my favorite choice), if your contract allows you to make that choice.

    Update: BTW, wasn't it M$ who sued people for faking HTTP user agent strings? I think they acually won the case (a decision I can't understand).

    Did they specify which system you must use when they gave you the contract?

    Yes? Then you're framed -- since you actually didn't deliver.

    No? Then they, AFAIB, cannot do anything about your choice. They might choose not to use your work, but they'll certainly have to pay for it, as long as it functionally provides what they ordered. If they insist on porting your work, they'd have to pay for that separately (since that would be another order/job).

    Do you run the service? Is it a service you are paid to run? If yes, then it's just the typical manner of M$ in trying to put pressure on people, to force them into decisions they think are ok with them. Which is really none of their business. It's my eternal hope that the market one day will respond, and that such practice won't prevail. If they pay you for the service (not the implementation details), they can't touch you legally, I'd think.

    Of course, the question is whether you'd want to meet M$ "lawyers" at high noon...

    So long,
    Flexx

      Load IIS and Apache... Change the port of apache to 81, and have an HTTP refresh on the IIS default page to the :81 port

      ;-)

Re: Altering "Server" HTTP Header Param
by valdez (Monsignor) on Oct 14, 2002 at 23:35 UTC

    Don't forget to create ErrorDocument pages or a stupid 404 will uncover your trick...

    Ciao, Valerio

Re: Altering "Server" HTTP Header Param
by true (Pilgrim) on Oct 14, 2002 at 21:38 UTC
    I love your 'solution', although devious, it's got moxy. Do you have WebMin running (root access)? You can change the server info file with webmin (set a custom header file). Another even better trick would be to put a redirect in your dns which redirects the request from netcraft's ip to a special perl script. The perl script could output what looked like a server line.
    You will then be running a Mucrosoft webserver.

    Feel free to forward your boss lady the millions of complaints from IIS virus haters everywhere. Da penguin's da bomb!
    To clarify, redirect to a perl script which listens on
    another socket locally. To mimic the http protocol.
    It could be done but i wouldn't want to do it ;>
Re: Altering "Server" HTTP Header Param
by Jaap (Curate) on Oct 14, 2002 at 22:41 UTC
    If the boss want you to use a IIS webserver, she will provide you with one. If she does, put a little redirect perl script on the IIS server to your current or some other LAMP (Linux, Apache, MySQL, Perl) server.

    This would work unless this means you'd have to pay for the LAMP server yourself (raise a fund, every decent visitor here will donate ;-)
Re: Altering "Server" HTTP Header Param
by cluka (Sexton) on Oct 14, 2002 at 21:38 UTC
    See what happens when you sell your soul to the Devil??? ;)
Re: Altering "Server" HTTP Header Param
by Jeppe (Monk) on Oct 15, 2002 at 15:43 UTC
    What you do is insufficient. Have you ever played with nmap? It is capable of guessing the operating system by probing the TCP implementation.

    If you really want to get away with this, besides the legal problems, you will want to make a windows machine proxy everything while doing the actual calls to the apache server.

    However, I must agree with the other comments about legal issues.

    If your client failed to specify acceptable platform software, you might get the money by legal moves and then your client will have to pay for a second copy that complies to their new, accurate specification.

    In general, I consider proper specification and acceptance criteria vital to any code-for-hire development, and most development in general.

Re: Altering "Server" HTTP Header Param
by Steve_p (Priest) on Oct 14, 2002 at 21:49 UTC
    I'm getting discouraged, though. I think I'm screwed.

    Looking at this documentation, you may be right.

    The Header directives are processed just before the response is sent by its handler. These means that some headers that are added just before the response is sent cannot be unset or overridden. This includes headers such as "Date" and "Server".
Re: Altering "Server" HTTP Header Param
by cluka (Sexton) on Oct 15, 2002 at 16:30 UTC
    Gotta agree with the other comments on the business side of this decision. You don't want to get caught "faking it" by Microsuck - you think you're in trouble now! Not to make it worse, but if you "fake it" you only give the open-source community a bad name and ammo to the enemy. Your and our integrity are (to some degree) on the line. Check the contract - they're the Skulls, and your that wussy kid Josh Something from Dawson's Creek, but you can beat them if you have an out on paper. If they didn't specify which platform, server, etc to use, you're in the sweet spot. Let them know you'll port your stuff over, but for a fee. That's the one great part of this deal - you might be able to stick it to Redmond one more time. Sweet!