2 Replies Latest reply on Aug 17, 2004 7:59 PM by 807567

    Disabling HTTP TRACE in iPlanet 6.0 SP5

    807567
      Hello.

      I am running iPlanet 6.0 SP5 on Solaris 8 and am having trouble disabling the HTTP trace option. I have applied the obj.conf fix as described at http://sunsolve6.sun.com/search/document.do?assetkey=1-26-50603-1&searchclause=security but am not having any luck. I first tried putting the change on one line, i.e.,
      <Client method="TRACE">
      AuthTrans fn="set-variable" remove-headers="transfer-encoding" set-headers="content-length: -1" error="501"
      </Client>
      then tried breaking it out, as described at http://swforum.sun.com/jive/thread.jspa?forumID=16&threadID=21372 , reply #1.
         <Client method="TRACE">
         AuthTrans fn="set-variable"
                   remove-headers="transfer-encoding"
                   set-headers="content-length: -1"
                   error="501"
         </Client>
      With each attempt, I saved the file, restarted the server, and telnet'ed into my HTTP listening port. If I test using
         TRACE / HTTP/1.0
         HOST:myhost
      I get a seemingly correct result:
         HTTP/1.1 501 Not Implemented
         Server: Netscape-Enterprise/6.0
         Date: Mon, 16 Aug 2004 20:54:24 GMT
         Content-length: 148
         Content-type: text/html
         Connection: close
      
         <HTML><HEAD><TITLE>Not Implemented</title></head>
         <BODY><H1>Not Implemented</h1>
         This server does not implement the requested method.
         </body></html>Connection closed by foreign host.
      However, if I test with:
      TRACE / HTTP/1.1 
      I get
      HTTP/1.1 413 Request Entity Too Large
      Server: Netscape-Enterprise/6.0
      Date: Mon, 16 Aug 2004 20:55:47 GMT
      Content-length: 168
      Content-type: text/html
      Connection: close
      
      <HTML><HEAD><TITLE>Request Entity Too Large</title></head>
      <BODY><H1>Request Entity Too Large</h1>
      A request entity is longer than the server can handle.
      </body></html>Connection closed by foreign host.
      If instead of the TRACE command I enter
      OPTIONS * HTTP/1.0
      I get
      HTTP/1.1 404 Not found
      Server: Netscape-Enterprise/6.0
      Date: Mon, 16 Aug 2004 20:57:42 GMT
      Content-length: 292
      Content-type: text/html
      Connection: close
      
      <HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=ISO-8859-1"><TI
      TLE>Not Found</title></head>
      <H1>Not Found</h1> The requested object does not exist on this server. The link 
      you followed is either outdated, inaccurate, or the server has been instructed n
      ot to let you have it. Connection closed by foreign host.
      And if I enter
      OPTIONS * HTTP/1.1 
      I get
      HTTP/1.1 200 OK
      Server: Netscape-Enterprise/6.0
      Date: Mon, 16 Aug 2004 21:00:01 GMT
      Content-length: 0
      Allow: HEAD, GET, PUT, POST, DELETE,TRACE, OPTIONS, MOVE, INDEX, MKDIR, RMDIR
      The server error log is clean following all these commands. Questions:

      1) Why would TRACE and OPTION request specifying HTTP 1.0 vs. 1.1 yield such different results? Especially strange is the fact that the only command yielding the expected result was a TRACE request specifying HTTP 1.0 (even though all server responses are specifying 1.1)
      2) Is the OPTIONS command a legitimate test of whether this fix works? If it is, has anyone managed to have the command return an "Allow:" line MINUS the TRACE?
      3) Has anyone managed to generate a 501 error message after specifying TRACE / HTTP/1.1 instead of 1.0?
      4) Does this fix really work?

      Thanks. Peter
        • 1. Re: Disabling HTTP TRACE in iPlanet 6.0 SP5
          807567
          1) Why would TRACE and OPTION request specifying HTTP 1.0 vs. 1.1 yield such different results?

          Web Server 6.0 only implements the TRACE and OPTIONS methods for HTTP/1.1, not HTTP/1.0. This is reasonable as TRACE and OPTIONS are part of the HTTP/1.1 protocol and not the HTTP/1.0 protocol.

          In other words, TRACE is always disabled for HTTP/1.0 requests, even if you don't use the set-variable work around.

          2) Is the OPTIONS command a legitimate test of whether this fix works? If it is, has anyone managed to have the command return an "Allow:" line MINUS the TRACE?

          Nope, not in Web Server 6.0. OPTIONS will always list TRACE. (Note that in Web Server 6.1, TRACE is not as tightly integrated into the server core. As a result, OPTIONS will conditionally list TRACE in 6.1.)

          3) Has anyone managed to generate a 501 error message after specifying TRACE / HTTP/1.1 instead of 1.0?

          Nope, not in Web Server 6.0.

          4) Does this fix really work?

          I wouldn't call it a fix; it's a work around. However, it does effectively disable TRACE. The work around is a bit of a kludge, resulting in the odd 413 status code.

          The real "fix" appears in Web Server 6.1 where you can disable TRACE simply by commenting out the Service method="TRACE" fn="service-trace" line in obj.conf.
          • 2. Re: Disabling HTTP TRACE in iPlanet 6.0 SP5
            807567
            Thanks for detailed reply!

            Will now stop banging head against wall.

            Score: Wall 1, Peter 0

            Peter