2007년 8월 27일 월요일

Windows 2003 Serve IIS6에서 “Bad Request (Invalid Header Name)” 에러 발생

[문제사항]

“Bad Request (Invalid Header Name)”

또한 WebAgent로 호출된 부분이 정상적으로 처리가 안되고 빨간색(Not Found)와 같은 형태로 나타남. è URL copy하여 브라우저에서 실행을 하면 WebAgent(wa_isapi.dl)정상적으로 인식이 된다.

이로 볼 때 IIS6.0(Windows 2003 Server)에서 에러를 발생 시킨 것으로 보인다. 이를 검색 사이트에서 검색해본 결과 하단의 참고자료를 얻을 수 있었다.

 

 

 

해결방법 :                                                                                                                  

Windows 2003 Server를 인스톨하고 보안 Update및 추가 Update를 하지 않은 상태여서 이를 Update하고 다시 테스트 하도록 유도함.

하단의 http://support.microsoft.com/kb/828726 hotfix를 참고하십시요.

 

참고자료 :                                                                                                                  

http://www.derkeiler.com/Newsgroups/microsoft.public.inetserver.iis.security/2004-03/0437.html

 

Re: Web Site is down! after upgrade

From: Desmond Lam (deslam_at_online.microsoft.com)
Date: 03/17/04

·         Next message: Desmond Lam: "Re: HTTP 401.2 - Unauthorized: Logon failed due to..."

·         Previous message: Desmond Lam: "Re: SSL & "All Unassigned""

·         In reply to: Ari: "Web Site is down! after upgrade"

·         Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]


Date: Wed, 17 Mar 2004 12:07:51 +0800

 

By default IIS 6.0 only serves statics HTML pages. If you are just serving
out static pages, there should not be any problem with IIS 6. If you are
running custom apps like ASP/CGI etc, you may need to specifically enable
the options to run them . Otherwise, try setting IIS6.0 to run in IIS 5
isolation mode and see if it resolves the issue. If it does, the problem is
probably related to the architecuture change in IIIS6.0 (http.sys and worker
process concept)

Some Additional Information for your reference when using IIS 6.0 Worker
Process Mode:

1. In Microsoft Internet Information Services (IIS) 6.0, when a request
contains a header name that includes a question mark (?) character or
another separator character, Http.sys rejects the request and sends the
following error message to the requestor:

 Bad Request (Invalid Header Name).

Additionally, when you use lowercase HTTP verbs like "get," Http.sys rejects
the request and sends the following error message to the requestor:

 "Bad Request (Invalid Verb)".

Refer to the KB for resolution/workaround:
FIX: Http.sys Rejects Requests That Contain Separator Characters
http://support.microsoft.com/?id=828726

2. KB: Information about ISAPI filters with SF_NOTIFY_READ_RAW_DATA in IIS
6.0
http://support.microsoft.com/?id=311852

3. Error Message: HTTP/1.1 Error 400 - Bad Request
http://support.microsoft.com/?id=247249

Hope it helps
Desmond

"Ari" <anonymous@discussions.microsoft.com> wrote in message
news:CE39512A-B07C-4D64-8A03-E03D2A6BD28A@microsoft.com...
> After upgrading to windows 2003 server when a user access our site they
get the following error
> The page cannot be found HTTP 400 - Bad Request
> I've check everything on the server including anonymous access,
permissions, can't figure it out!
>
> Any help is greatly appreciated

 

 

첨부자료 :                                                                                                                  

[참고문서]

http://support.microsoft.com/kb/828726

 

FIX: Http.sys에서 구분 문자가 포함된 요청을 거부한다

문서가 적용되는 제품 보기.

기술 자료 ID

:

828726

마지막 검토

:

2006 3 29일 수요일

수정

:

3.5

중요 이 문서에서는 레지스트리 수정 방법을 설명합니다. 레지스트리를 수정하기 전에 해당 레지스트리를 백업하고 문제 발생 시 이를 복원하는 방법을 이해해야 합니다. 레지스트리 백업, 복원 및 편집 방법은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

256986 (http://support.microsoft.com/kb/256986/) Microsoft Windows 레지스트리 설명

이 페이지에서

현상

원인

해결 방법

핫픽스 정보

전제 조건

다시 시작 요구 사항

핫픽스 대체 정보

파일 정보

현재 상태

추가 정보

HTTP 헤더에서 구분 문자 허용

대/소문자를 구분하지 않는 HTTP 동사 허용

현상

Microsoft 인터넷 정보 서비스(IIS) 6.0에서 요청에 물음표(?) 또는 다른 구분 문자를 포함하는 헤더 이름이 들어 있으면 Http.sys는 요청을 거부하고 다음과 같은 오류 메시지를 요청자에게 보냅니다.

잘못된 요청(잘못된 헤더 이름입니다.)

또한 "get"과 같은 소문자 HTTP 동사를 사용할 경우 Http.sys는 요청을 거부하고 다음과 같은 오류 메시지를 요청자에게 보냅니다.

"잘못된 요청(잘못된 동사입니다.)"

위로 가기

원인

이 문제는 HTTP 사양에서 헤더에 구분 문자가 포함된 HTTP 요청은 유효하지 않다고 지정하고 있기 때문에 발생합니다. 또한 HTTP 사양에서는 HTTP 동사가 대/소문자를 구분한다고 지정하고 있습니다.

위로 가기

해결 방법

핫픽스 정보

현재 지원되는 핫픽스를 Microsoft에서 구할 수 있지만 이 문서에서 설명하는 문제를 해결하기 위한 것일 뿐이므로 이러한 특정 문제가 발생하는 시스템에만 이 프로그램을 적용해야 합니다. 이 핫픽스는 나중에 추가 테스트를 받아야 할 수도 있습니다. 따라서 이 문제의 영향이 심각하지 않으면 이 핫픽스가 포함된 다음 Microsoft Windows Server 2003 서비스 팩이 나올 때까지 기다리는 것이 좋습니다.

이 문제를 즉시 해결하려면 Microsoft 고객기술지원부에 문의하여 핫픽스를 구하십시오. Microsoft 고객기술지원부 전화 번호의 전체 목록과 지원 비용에 대한 정보는 다음 Microsoft 웹 사이트를 참조하십시오.

기술지원 서비스 안내 (http://support.microsoft.com/default.aspx?scid=fh;ko;serviceoverview)

참고 특정 업데이트로 문제를 해결할 수 있다고 Microsoft 기술 지원 전문가가 판단할 경우 지원 요청에 따른 일반적 비용이 취소될 수도 있습니다. 특정 업데이트가 필요하지 않은 추가 지원 질문과 문제에는 일반 지원 비용이 적용됩니다.

전제 조건

전제 조건이 없습니다.

다시 시작 요구 사항

이 핫픽스를 적용한 후에는 컴퓨터를 다시 시작해야 합니다.

핫픽스 대체 정보

이 핫픽스는 다른 핫픽스를 대체하지 않습니다.

파일 정보

이 핫픽스의 영어 버전은 아래와 같거나 그 이상의 파일 특성을 갖고 있습니다. 이 파일의 날짜와 시간은 UTC(Coordinated Universal Time)로 나열되며 파일 정보를 볼 때 로컬 시간으로 변환됩니다. UTC와 로컬 시간의 차이를 알려면 제어판날짜 및 시간 도구에서 표준 시간대 탭을 사용하십시오.

날짜

시간

버전

크기

파일 이름

2003-09-25

22:35

5.2.3790.89

334,336

Http.sys

2003-09-25

23:59

5.2.3790.89

27,648

Httpapi.dll

 

위로 가기

현재 상태

Microsoft "본 문서의 정보는 다음의 제품에 적용됩니다." 절에 나열한 제품에서 이 문제를 확인했습니다.

위로 가기

추가 정보

경고 레지스트리 편집기를 잘못 사용하면 심각한 문제가 발생할 수 있으며 문제를 해결하기 위해 운영 체제를 다시 설치해야 할 수도 있습니다. Microsoft는 레지스트리 편집기를 잘못 사용함으로써 발생하는 문제에 대해 해결을 보증하지 않습니다. 레지스트리 편집기의 사용에 따른 모든 책임은 사용자에게 있습니다.

일부 클라이언트는 HTTP 사양을 엄격하게 따르지 않기 때문에 이 핫픽스를 설치하고 다음 레지스트리 키를 설정하면 이러한 제약 사항이 완화될 수 있습니다.

위로 가기

HTTP 헤더에서 구분 문자 허용

다음과 같이 한 다음 레지스트리 편집기를 종료하십시오.

1.

시작, 실행을 차례로 누르고 regedit를 입력한 다음 확인을 누릅니다.

2.

레지스트리에서 다음 키를 찾아 누릅니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

3.

편집 메뉴에서 새로 만들기를 가리킨 다음 DWORD 을 누릅니다.

4.

AllowWeakHeaderNameSyntax를 입력한 다음 Enter 키를 누릅니다.

5.

편집 메뉴에서 수정을 누릅니다.

6.

1을 입력한 다음 확인을 누릅니다.

참고 이 변경 내용을 적용하려면 컴퓨터를 다시 시작해야 합니다.

위로 가기

/소문자를 구분하지 않는 HTTP 동사 허용

다음과 같이 한 다음 레지스트리 편집기를 종료하십시오.

1.

시작, 실행을 차례로 누르고 regedit를 입력한 다음 확인을 누릅니다.

2.

레지스트리에서 다음 키를 찾아 누릅니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

3.

편집 메뉴에서 새로 만들기를 가리킨 다음 DWORD 을 누릅니다.

4.

AllowCaseInsensitiveVerbs를 입력한 다음 Enter 키를 누릅니다.

5.

편집 메뉴에서 수정을 누릅니다.

6.

1을 입력한 다음 확인을 누릅니다.

참고 이 변경 내용을 적용하려면 컴퓨터를 다시 시작해야 합니다.

 

 

 

ODBC를 이용하여 DB2 사용시 SQL7008 에러 발생

[문제점]

DB2를 ODBC를 사용하여 연결 시 아래와 같은 에러가 발생됨

(Error originState HY000, Error [IBM][iSeries Access ODBC 드라이버]

[DB2 UDB]SQL7008 - SFPFMKD in SFALIB not valid for operation.)

[원인 분석]

 

에러분석 :                                                                                                                  

SQL7008 에러가 발생하는 것은 서버의 DataBase(DB2)의 권한 이나 ODBC의 환경 설정에서 Transaction 권한이 없는 경우에 발생 할 수 있다. 이에 대한 설정 중 DB2에 대한 설정은 언급하지 않겠다.

이문서는 ODBC 설정에 대하여 언급하도록 하겠다.

 

해결방법 :                                                                                                                  

DB2는 네 종류의 분이(Isolation) 레벨을 갖는다. ODBC Client의 설정을 통해 최적의 isolation level을 설정 할 수 있다.

è  Isolation level dirty ready, phantom reads 그리고 non-repeatable reads 와 같은 데이터 무결성 문제에 대해 어떻게 데이터를 보호하고 처리할 것인지를 결정하는 방법이다.

Default 값으로 Read uncommitted(*CHG) 로 설정이 되어 있다. 자세한 내용은 아래 동시성(Concurrency)를 참고하기 바란다.

이를 해결하기 위해 ODBC 설정에서 Commit ModeCommit Immediate(*NONE)을 선택한다.

ODBC DataSource 관리 è System DSN è 등록정보 è Server è 고급(확장) è Commit Mode 설정

참고자료 :                                                                                                                  

 

동시성(Concurrency)의 관리

다수의 동시 사용자들을 갖는다면, 그들의 활동의 상호작용에 대해 관리할 필요가 있다. , 각각의 사용자들이 어느 정도로 독립적으로 활동하고 있는 지를 결정할 필요가 있다. 관리해야 할 대상은 독립(Independence)의 정도 또는 다른 사용자들로부터 한 사용자의 분리(Isolation)의 정도이다. DB2는 네 종류의 분리(Isolation) 레벨을 갖는 데, 매우 분리(Isolation)되는 레벨에서 분리(Isolation)되지 않는 레벨까지 기술하면 다음과 같다.

 

l  반복 읽기(Repeatable Read)란 마지막 확약시점이후부터 다음 확약시점까지 응용프로그램에 의해 액세스되는 모든 행들에 잠금(Lock)을 유지한다. 만약 응용프로그램이 동일한 행을 다시 읽으려고 한다면, 그 값은 변경될 수 없다. 이 분리(Isolation)의 효과는 한 응용프로그램이 다른 응용프로그램이나 다른 사용자들로부터 테이블의 변경을 가하지못하도록 할 경우에 적용될 수 있다. 결과적으로 전반적인 동시성(Concurrency)이 감소될수 있다.

 

l  읽기 안정성(Read Stability)이란 하나의 단위작업(Unit Of Work)이 완료될 때까지 응용프로그램에 의해 액세스되는 모든 조건에 합당하는 행들에 잠금(Lock)을 유지한다. 다른 응용프로그램에 의한 변경되는 행들은 그들 응용프로그램에 의해 변경되는 행들이 확약될 때까지 그 행들을 읽을 수 없다. 한 응용프로그램이 동일한 조회를 한번 이상 하게 되면, 새로운 행이나 변경된 행들을 읽을 수 있다.

 

l  커서 안정성(Cursor Stability)이란 커서가 그 행에 위치하는 동안에만 그 행에 잠금(Lock)을 유지한다. 커서가 한 행에서 다른 행으로 이동하면 잠금(Lock)이 풀린다. 그러나 데이터가 변경되면 데이터가 확약될 때까지 잠금을 유지해야 한다. 따라서 커서 안정성은 데이터를 읽을 경우에만 적용된다. 모든 변경된 데이터들은 COMMIT 또는 ROLLBACK이 수행될 때까지 잠금(Lock)을 유지한다.

 

l  미확약 읽기(Uncommitted Read)란 잠금(Locks)에 의한 대기없이 행들을 볼 수 있도록 한다. 이는 읽기전용 또는 SELECT문에서만 적용된다. 그 외의 작업에서만 커서 안정성과  같은 방식으로 수행된다. 분리(Isolation) 레벨을 사용하는 한 응용프로그램은 다른 응용프로그램에 의해 미확약된 변경값을 포함하는 모든 행을 읽을 수 있다. 이 분리(Isolation) 레벨을 사용하면 동시성 잠금(Concurrency Lock)을 위해 대기할 수 없기  때문에 전반적으로 성능을 향상시킬 수 있다.

 

분리(Isolation) 레벨은 사전 컴파일(PreCompile)시 또는 한 어플리케이션 프로그램이 데이터베이스에 바인드(Bind)될 때 지정될 수 있다. 만약 아무런 분리(Isolation) 레벨을 지정하지 않으면, 생략시값인 커서 안정성이 사용된다. 패키지에 사용된 분리(Isolation) 레벨을 보려면 제어센터의 객체트리내의 패키지 폴더를 선택한다.

 

 

 

첨부자료 :                                                                                                                  

[참고문서]

http://www-912.ibm.com/s_dir/slkbase.NSF/643d2723f2907f0b8625661300765a2a/31821151773d0613862569b200550644?OpenDocument

 

IBM Software Technical Document

__________________________________________________________________
Document Information
Document Information

Document Number:

21653409

Functional Area:

Client Access

Subfunctional Area:

ODBC

Sub-Subfunctional Area:

Configuration

OS/400 Release:

V4R5M0; V5R1M0; V5R2M0; V5R3M0; V5R4M0

Product:

CA/400 WIN 95 EXPRESS CLIENT (5769XE100)
IBM ISERIES CLIENT ACCESS EXP (5722XE100)

Product Release:

N/A



__________________________________________________________________

Document Title
iSeries Access ODBC: Commit Mode Data Source Setting, Isolation Level, and Autocommit

Document Description

Important Note: This document discusses Client Access for Microsoft® Windows® 95 and Windows NT®, Client Access Express, and IBM® iSeries™ Access products. These names essentially refer to the same product; however, the functionality and name changed over the last several releases. For the purposes of this document, the terms Client Access, Client Access Express, and iSeries Access may be used interchangeably. Where a difference is important, the version of the product is used to identify the differences.


The iSeries Access for Windows ODBC Datasource has an option for Commit mode. This is the default isolation level that will be used if an application does not specifically set it. An isolation level specified by the application always overrides the value set in the data source.

ODBC defines autocommit and isolation level as two different connection properties. Both properties are set at the connection level via the SQLSetConnectAttr API using the SQL_TXN_ISOLATION and SQL_AUTOCOMMIT parameters. iSeries Access provides a commit mode property because some applications allow the user/programmer to set autocommit off but they do not expose the isolation level property. For example, the Microsoft DAO and RDO object models allow a programmer to set autocommit off; however, they do not allow any direct changes to the isolation level.

In R450 and earlier of Client Access, the default isolation level for Client Access is a proprietary DB2/400 isolation level of *NONE. Setting autocommit off with the default isolation level of *NONE has no effect - *NONE is similar to autocommit yes, isolation level Read Uncommitted. In this case, commits and rollbacks have no effect. Applications such as these need to set the datasource to the desired isolation level. In the case of RDO, another option is for the programmer to retrieve the connection handle and call the SQLSetConnectionOption API directly.

In R510 and later, the default isolation level was changed to *CHG (read uncommitted). This change in behavior was made so the default behavior of iSeries Access for Windows better matches the default used by the other DB2 platforms. Note that this change may cause existing applications to encounter the following error:

SQL7008 return code 3 - &1 in &2 not valid for operation. The reason code is 3. Reason Code 3 -- &1 not journaled, or no authority to the journal.

To avoid this message, journal the target files or change the commit mode setting in the data source to *NONE.

Autocommit On
The default behavior of iSeries Access for Windows is to map SQL_AUTOCOMMIT_ON to DB2/400 isolation level *NONE. This is not strictly compliant with the ODBC specification. It offers the best performance with no journaling required. Note that dirty reads are possible regardless of the isolation used. Applications that call triggers or procedures (particularly nested procedures) using isolation levels other than *NONE may encounter unpredictable results.

The R530 release of iSeries Access for Windows adds a new connection keyword that allows for an autocommit on setting that complies to the SQL specification. The new keyword is trueautocommit. It can be used in the connect string or added to a data source. A value of 1 indicates that the driver should strictly adhere to the specification, that is, it will run autocommit under any isolation level. The active isolation level is used even when autocommit is on. The disadvantages of this setting are that all files must be journaled which might result in slower peformance. Large insert, update and delete operations in particular can be signifcantly slower.

The cwbodbcreg utility can be used to add the trueautocommit keyword to an existing datasource. The tool is included in iSeries Access for Windows. The syntax for the tool is:
cwbodbcreg <DSN Name> trueautocommit <value>

A value of 1 enables true autocommit.
A value of 0 (the default) results in autocommit being implemented using *NONE isolation level.


Isolation Level Mappings

The following table shows how ODBC isolation levels relate to the DB2 UDB for iSeries isolation levels.



Figure 1 shows the location of the commit mode setting in the iSeries Access for Windows data source configuration.