Troubleshooting HTTP Server

Symptom: Error 404 on HTTP Server

Cause

HTTP Server is not able to find the resource that was requested or the user profile on HTTP Server does not have authority to the requested resource.

Solution

Check the following:

• Make sure the file exists.
• Make sure that the user profile used to access the resource has object authority. The user profile QTMHHTTP is used by default. The user profile QTMHHTP1 is used by default when the request is a CGI program.

Symptom: HTTP Server has a slow response

Solution

Refer to the following:

• Managing HTTP Server performance

Symptom: Error 500 on HTTP Server

Cause

A program on your HTTP Server has failed or there is an error in your CGI program.

Solution

Check the following:

• Check the server Primary job log, QSYSOPR messeges, error log and CGI job logs for more information.
• If you have not used the IBM Web Administration for i interface to create an HTTP Server configuration, a required directive may be missing from the configuration file. View the configuration file with the Web Administration for i interface for possible errors.

Symptom: HTTP Server on port 80 does not start

Cause

By default, APACHEDFT server autostart setting is *GLOBAL. If, in addition, the global server setting for autostart is "Yes", then APACHEDFT server will start during STRTCP command processing. APACHEDFT server uses port 80 and may cause any other HTTP Server using port 80 to not start.

Solution

Do the following:

If you HTTP Server does not start or appears to start, but then stops, check the following:

1. The cause of the problem may be in the job log. Use WRKACTJOB immediately after the server is started. If the job is active, the enter WRKACTJOB to work with job and display the job log. If the job is not active, then enter WRKSPLF SELECT(QTMHHTTP) to find the name of the server and display the spool file.
2. If you have configured the error logs, then the cause of the problem may be in the error log. For example, /www/myserver/logs/basic_error_log, where "myserver" is the name of your HTTP Server.
   Note: If the error messages have been customized, the error will not be identified in the same manner as the above example.

If these steps do not help, then try starting the server with verbose tracing. See Manage server performance for HTTP Server for tracing.

By default, APACHEDFT server autostart setting is *GLOBAL. If, in addition, the global server setting for autostart is "Yes", then APACHEDFT will start during STRTCP command processing. APACHEDFT server uses port 80 and may cause any other HTTP Server using port 80 to not start. To avoid this condition, you can :

• Change APACHEDFT server configuration autostart setting to "No".
• Change APACHEDFT server configuration to use a port other than 80.

To change the autostart value on APACHEDFT server, do the following:

1. Click the Manage tab.
2. Click the HTTP Servers subtab.
3. Select APACHEDFT from the Server list.
4. Expand Server Properties.
5. Click General Server Configuration.
6. Click the General Settings tab in the form.
7. Select No (instead of *GLOBAL or Yes) from the Autostart list.
8. Click OK.

To change the port number on APACHEDFT server, do the following:

1. Click the Manage tab.
2. Click the HTTP Servers subtab.
3. Select APACHEDFT from the Server list.
4. Expand Server Properties.
5. Click General Server Configuration.
6. Click the General Settings tab in the form.
7. Select the IP address and port from the Server IP addresses and ports to listen on table.
8. Enter a new value for the port number in the Port column.
9. Click Continue.
10. Click OK.

As a final precaution, make sure APACHEDFT server is not started by doing the following:

1. Click the Manage tab.
2. Click the All Servers subtab.
3. Click the All HTTP Servers tab.
4. Select APACHEDFT from the table.
5. Click Stop.

Symptom: Web browser problems with HTTP Server

Cause

Your Web browser may not be configured correctly.

Solution

Below is a list of common problems and solutions for your Web browser.

Miscellaneous Microsoft Internet Explorer errors related to incorrect interpretation of HTTP/1.1 in response

Microsoft Internet Explorer sends requests in HTTP/1.1 format but seems to only accept responses in HTTP/1.0 format. The work around is to tell HTTP Server the request came in as HTTP/1.0 format.

Fore example: BrowserMatch "MSI 4\.0b2;" downgrade-1.0 force-response-1.0

URL not found when clicking on a file in a directory listing from Netscape

If AlwaysDirectoryIndex is set to OFF and a URL for a directory without a trailing slash is requested, then Netscape does not request the file relative to the director in which the file exists in the resulting directory listing.

Microsoft Internet Explorer does not display customized error messages

If Internet Explorer is not displaying the customized error messages, check to see if the preferences for the browser are set to show friendly HTTP error messages. Disable this preference and the customized error massages should display properly.

When using HTTPS, Microsoft Internet Explorer shows pages that were cached when using HTTP

If the browser is showing cached pages instead of connecting to the server using SSL, clear the browser's cache.

Prompted for password when using certificate for client authentication

If you are using a Certificate Authority that offers the option to protect the private key of your certificate with a password (such as for the Microsoft Internet Explorer browser), and you use the certificate for client authentication, you are prompted for the password after about 2 minutes of idle time. This happens even if you have disabled SSLV2 in the browser being used and in the server because you are trying to use the longer SSLV3 cache time-out interval. This is a security feature that protects your private key if you are away form your client, even though it may look like an SSLV3 caching problem.

Certificate not recognized by browser

If you add a certificate to your browser, the browser may not recognize that there is a new certificate until you restart your computer.

Symptom: HTTP Server will not start or functions will not work

Solution

General items to check:

1. Check /QIBM/UserData/HTTPA/admin/logs, HTTPAdmin.log, error_log, and any other logs you may have. More information on the cause of the problem may be found there.
2. Use CHKPRDOPT to 57XXDG1, SS1, TC1 and JV1.
3. Check joblog for user QTMHHTTP.
4. Check QTMHHTTP and QTMHHTP1 user profiles.
5. Verify that *PUBLIC is not *EXCLUDEd from '/' (Use WRKLNK '/' and take option 9).
6. Verify that QSERVER and QUSRWRK subsystems are running.

Error messages:

Error ZSRV_MSG0358

Found in admin log. Verify that there is a host table entry in CFGTCP Option 10 that matches the host + domain name in CFGTCP Option 12, and set 'Host Name Search Priority' to *LOCAL.

Error ZUI_50004 - 'no *IOSYSCFG authority'

Verify that user has *IOSYSCFG Authority. If *IOSYSCFG is granted by a GROUP profile, verify that PTF SF65588 (V4R5) is applied. Check that there are NO user .jar files in the /QIBM/ProdData directory path - this directory is for IBM use only.

Error HTP8015

Verify that the latest PTFs for DG1 product are applied.

Error CEE0200

Verify that 57XXJV1 Options *Base, 5, and 6 are installed,

Error ZSRV_MSG0302 :User qsecofr:authentication failure for "/":1

Known problem with 128 character passwords on V5R1. HTTP servers cannot use 128 character passwords. You may be able to circumvent this problem by changing the password in the user profile to CAPITAL letters and using CAPITAL letters to log into the ADMIN screen.

Symptom: Error occurred opening file

Cause

If your HTTP Server configuration uses the Rewrite directive and does not have the proper access for QTMHHTTP configured, your server will not start.

Solution

Make sure QTMHHTTP has *RWX access authority to the /tmp directory.

Symptom: WebSphere Portal authentication performance problems

If you are experiencing performance problems when users are logging into Portal (the authentication phase), the following indicators may help determine that the filters are causing these performance problems:

• Your LDAP server is populated with a large number of entries.
• When you type WRKACTJOB in a console command line, QSQSRVR jobs are using an excessive amount of CPU during the Portal authentication (sign on) phase.
• When two Portal users sign on concurrently, one sign on request takes two times as long as the other request.

Cause

You may encounter a performance problem if you configure a secure WebSphere® Portal server with LDAP. This problem only occurs if you use the Create WebSphere Portal wizard in the Web Administration for i interface. When configuring LDAP with the WebSphere Portal wizard, the two LDAP fields LDAPUserFilter and LDAPGroupFilter are configured with default values depending on the type of LDAP server being used. For example, if you are securing your WebSphere Portal server using the IBM Directory Server, the two LDAP fields are set to "(&(|(cn=%v)(uid=%v))(objectclass=person))" and "(&(cn=%v)(|(objectclass=groupOfUniqueNames)(objectclass=groupOfNames)(objectclass=group)))", respectively. By configuring the fields with the default values, the WebSphere Portal wizard allows the wpsadmin Portal administrator to successfully login and existing LDAP entries can be used once the Portal server is successfully configured and secured. However, if the LDAP server has a large number of entries, or if many additional users are added to the LDAP server, Portal's authentication performance may be noticeably impacted.

Solution

If you determine that the filters, as configured by the WebSphere Portal wizard, are causing authentication performance problems, complete the following steps:

1. Start the Web Administration for i interface.
2. Click the Manage tab.
3. Click the Application Servers subtab.
4. Expand Tools.
5. Click Launch Administrative Console.
6. Login to the console and click OK.
7. Expand Security.
8. Expand User Registries.
9. Click LDAP.
10. Click Advanced LDAP Settings in the Additional Properties table.
11. Edit the User Filter and the Group Filter properties values to more precise values to increase authentication performance. For more information about this syntax, see the IBM Tivoli® Directory Server for i (LDAP) and the WebSphere Portal and Lotus® Web Content Management Web site.

1. Edit the User Filter and the Group Filter properties values to more precise values to increase authentication performance. For more information about this syntax, see the IBM Tivoli Directory Server for i (LDAP) and the WebSphere Portal and Lotus Web Content Management Web site.
2. Click OK.
3. Click Save to apply changes to the master configuration.
4. Click Save again on the next page.

Note: You may need to restart your WebSphere Application Server for these changes to take affect.