서버가 받아들이는 것에“관대해야”하고“잘못된 입력을 자동으로 폐기”해야합니까?

나는 모든 사람이이 최대 값이 실수라는 데 동의한다는 인상을 받았다. 그러나 나는 최근에 137 번 찬성 된 "관대 한"의견을 가진 이 답변 을 보았다 .

제 생각에는 브라우저가 받아들이는 한계는 HTML과 몇 가지 다른 웹 표준이 몇 년 전에 있었기 때문에 완전히 혼란스러워하는 직접적인 원인이었으며 최근에는 그 혼란에서 제대로 결정화되기 시작했습니다. 내가 보는 방식, 당신이 받아들이 는 것에 관대 하면 이것으로 이어질 것 입니다.

최대 값의 두 번째 부분은 "사양에서 요구하지 않는 한 오류 메시지를 리턴하지 않고 결함이있는 입력을 자동으로 폐기합니다" 이며 경계선이 불쾌감을 느낍니다. 조용히 실패했을 때 벽에 머리를 부딪친 프로그래머라면 내가 무슨 뜻인지 알 것입니다.

그래서 나는 이것에 대해 완전히 잘못입니까? 내 프로그램이 오류를 자동으로 받아들이고 삼키는 것에 관대해야합니까? 아니면 이것이 의미하는 바를 잘못 해석하고 있습니까?

원래 질문은 "프로그램"이라고 말했고, 나는 그것에 대해 모든 사람의 의견을 취합니다. 프로그램이 관대하다는 것이 합리적입니다. 그러나 실제로 의미 하는 것은 사람들이 아닌 다른 프로그램에 노출되는 인터페이스 인 API 입니다. HTTP는 예입니다. 프로토콜은 다른 프로그램 만 사용하는 인터페이스입니다. 사람들은 "If-Modified-Since"와 같은 헤더에 들어가는 날짜를 직접 제공하지 않습니다.

따라서 문제는 표준을 구현하는 서버가 관대해야하고 표준에 실제로 요구되는 것 외에도 몇 가지 다른 형식의 날짜를 허용해야 하는가하는 것입니다. 나는 "관대하게"는 인간의 인터페이스보다는이 상황에 적용되어야한다고 생각합니다.

서버가 관대하다면 전반적인 개선처럼 보일 수 있지만 실제로는 클라이언트 구현 으로 인해 관대함에 의존하고 약간 다른 방식으로 관대 한 다른 서버와 작동하지 않는 것으로 생각합니다.

그렇다면 일부 API를 노출하는 서버는 관대해야합니까, 아니면 매우 나쁜 생각입니까?

이제 사용자 입력을 관대하게 처리합니다. YouTrack (버그 추적 소프트웨어)을 고려하십시오. 마크 다운을 연상시키는 텍스트 입력 언어를 사용합니다. "관심"이라는 것을 제외하고. 예를 들어

- foo
- bar
- baz

글 머리 기호 목록을 작성하는 문서화 된 방법 은 아니지만 여전히 효과가 있습니다. 결과적으로 내부 버그 추적기에서 많이 사용되었습니다. 다음 버전이 나오고이 관대 한 기능이 약간 다르게 작동하기 시작하여이 기능이 아닌 기능을 사용한 목록을 여러 개 나누었습니다. 글 머리 기호 목록을 작성하는 문서화 된 방법은 여전히 ​​유효합니다.

그렇다면 소프트웨어가 어떤 사용자 입력 을 받아 들여야합니까?

물론 당신은 완전히 옳습니다. 그렇게하는 것이 문제를 가리는 역할 만하기 때문에 프로그램은 결코 "관심"해서는 안됩니다. 깔개 밑으로 휩쓸 리지 말고 문제를 강조해야합니다. 유익한 오류 메시지는 프로그램이 사용자에게 도움이되기 위해 반드시 필요한 것입니다.

부정확하거나 유효하지 않은 데이터가 제공 될 때 대부분의 경우 해당 데이터 제공 업체 (사용자 또는 다른 프로그램의 출력 여부)가 유효하지 않은 것을 알지 못했을 것입니다. 오류를 삼키면 오류가 유효하거나 유효 할 수 있다는 신념을 유지하여 유효하지 않은 데이터가 확산됩니다.

시스템이 상호 운용되는 유일한 방법은 해당 상호 운용이 완전하고 명확하게 정의되는 것입니다. 사양 이외의 데이터를 받아들이는 프로그램 은 사양에 의해 무효 인 경우에도 사실상의 데이터를 받아 들여 호환성을 엄청나게 어렵게 할뿐 아니라 더 이상 공식적으로 정의하지 않음을 의미합니다. 프로그램 자체가 사실상 표준입니다. 따라서 관대 한 프로그램은 운영 방식을 미세하게 변경할 수 없기 때문에 더 이상 개발하거나 대체 할 수 없습니다.

타겟 인구 통계에 따라 달라집니다. 프로그래머라면 절대 그렇지 않습니다. 당신의 프로그램은 열심히 실패하고 피의 살인을 외 치게됩니다. 그러나 대상 독자 가 프로그래머 가 아닌 경우 예외를 정상적으로 처리 할 수있는 곳에서는 프로그램이 관대해야합니다. 그렇지 않으면 달콤한 피의 살인을 속삭이십시오.

사례 연구로 NPAPI Flash 플레이어를 사용하십시오. 실제로 발생할 수있는 오류의 약 99 %를 신경 쓰지 않는 사람들을위한 "릴리스"버전이 있지만 문제가 발생했을 때 피의 살인을 외치도록 사용할 수있는 "디버그"버전도 있습니다. 각각 플래시 콘텐츠를 지원하지만 완전히 다른 두 인구 통계를 대상으로합니다.

결국 중요한 것은 사용자가 무엇에 관심을 가지는 가라고 생각합니다.

"자동"의 두 가지 유형이 있습니다. 하나는 잘못된 입력을 받아들이고 이해하려고하는 것이고 다른 하나는 다른 유형의 입력을받는 것입니다.

일반적으로 가능할 때 항상 두 번째 것을 원합니다. 첫 번째는 당신이 빠르고 열심히 죽을 때입니다. 예 : 날짜.

다음은 유효, 무효 및 모호한 입력을 포함하는 몇 가지 입력 예입니다.

• 2011-01-02
• 01/02/2011
• Jan 2, 2011
• 2-Jan-2011
• Green

여기에 잘못된 입력이 하나 있습니다 : Green. 날짜로 받아들이지 마십시오. Green분명히 날짜가 아니기 때문에 자동 실패가 허용되는 경우입니다.

01/02/2011유효하지만 모호합니다. 미국 날짜 (1 월 2 일)로 입력되었는지 아닌지 (2 월 1 일) 여부를 반드시 알 필요는 없습니다. 여기서 큰 소리로 실패하고 사용자에게 명확한 날짜를 요청하는 것이 가장 좋습니다.

2011-01-02일반적으로 애매 모호한 것으로 간주되므로 "YYYY-MM-DD"형식으로 가정하여 계속 실패하는 것이 좋습니다. 그러나 사용자 입력을 처리 할 때 약간의 판단이 필요합니다.

Jan 2, 2011그리고 2-Jan-2011그들이 받아 들여야 유효하고 모호하다. 그러나 The Second of January of the year 2011이며 또한 유효하고 모호하지만,가는 먼 것을 관용을 위해서가 과잉이다. 다음과 같이 자동으로 실패하십시오 Green.

한마디 로 대답은 "의존"입니다. 입력 할 수있는 항목을 살펴보고 충돌하는 입력 유형 (예 : DD/MM/YYYYvs MM/DD/YYYY)을 절대 받아들이지 않도록하십시오 .

연계 된 질문 / 의견 과 관련하여 이는 사실이다 2011-01-02. 입력은 JSON처럼 보이고 mimetype이 틀리더라도 JSON처럼 유효성을 검사합니다. 계속해서 아래로 내려가도 실패하더라도 사용하십시오.

조용히 실패하는 것은 당신이 할 수있는 최악의 일입니다. 자동 실패로 API를 디버그하려고 했습니까? 그건 불가능합니다 .

"복구하기 위해 최선을 다하지만 자세한 오류를 보내십시오"와 "자동 실패"가 있습니다.

Postel의 법칙- "당신이하는 일에 보수적이며 다른 사람들로부터 받아 들여지는 것에 자유로 워야한다"는 것이 JSON 서비스에 대해 논의되고있는 것 같습니다. 이것은 일반적으로 UI가 아닌 웹 서비스에 적용됩니다.

UI의 건설적인 사용자 피드백과 사용자 입력 금지는 우리가 사용하는 규칙입니다.

나는 이것이 TAOUP의 1 장 6 절 에서 잘 다루고 있다고 생각한다 . 특히, 수리 규칙은 프로그램이 입력으로 수행 할 수있는 작업을 수행하고 올바른 데이터를 전달해야하며 올바른 응답이 실패하는 경우 최대한 빨리 수행해야한다고 명시하고 있습니다.

비슷한 개념은 방어 프로그래밍 입니다. 당신은 하지 않습니다 당신이받을 수 입력의 종류 알고 있지만 프로그램이 커버하는 강력한 충분해야 모든 경우를. 이 수단 알려진 망가 입력 등의 문제에 대한 복구의 경우이 프로그램되어야 하고 캐치 핸들 알려지지 않은 모든 경우.

따라서 입력 을 처리하는 한 잘못된 입력을 자동으로 버리는 것이 좋습니다 . 그대로 바닥에 떨어 뜨리면 안됩니다.

API의 경우, 관대함이 프로그램과 동일하다고 생각합니다. 입력이 여전히 잘못 되었지만 가능한 한 많은 수리를 시도하고 있습니다. 차이점은 유효한 수리 로 간주됩니다 . 지적했듯이, 관대 한 API는 사람들이 존재하지 않는 "기능"을 사용할 때 문제를 일으킬 수 있습니다.

물론 API는 구성 규칙의 하위 버전입니다 . 따라서 인터페이스이기 때문에 가장 놀라운 규칙에 따라 다루어 집니다.

Spencer가 인용 한 것처럼 "퍼지"입력에 대해 논할 수있는 피상적 유사성을 피하십시오. 이러한 조건에서 나는 일반적으로 원하는 것이 무엇인지 알지 못하기 때문에 모든 것이 수리 할 수없는 프로그램을 가리키고 있다고 생각합니다 .

그러나 많은 "표준"이 있는 날짜 를 처리하고 있습니다 . 때로는 단일 프로그램 (체인)에서 혼합되기도합니다. 날짜가 예상된다는 것을 알고 있으므로 날짜를 인식하는 것은 좋은 디자인입니다. 특히 날짜가 일부 외부 프로그램에서 왔고 수정되지 않은 채 1 초를 지나면 전달됩니다.

대부분 서버에 배포되는 프로그램은 1 분마다 또는 때로는 1 초마다 수천 건의 요청을 받아야합니다. 서버 프로그램이 클라이언트의 잘못된 입력을 받아 수정하면 두 가지 단점이 있습니다.

1. 귀중한 서버 시간 손실. 초당 1000 개 이상의 요청으로 각 요청에서 오류를 확인하면 각 클라이언트에 대한 응답이 느리게 반영 될 수 있습니다.
2. 올바른 입력을 제공하는 클라이언트 / 클라이언트 프로그램에 불공평합니다. 그 외에, 서버 측 프로그래머가 서버 코드에 앉을 때, 잘못된 입력이 무엇인지에 대한 다양한 경우에 대해 생각해야합니다. 누가 결정할까요?

서버 프로그램은 잘못된 입력을 받아들이지 않아야하지만 잘못된 입력이있는 경우 서버는 클라이언트에 오류 메시지를 반환해야합니다.

개념적으로 이상적인 동작은 안전하게 수행 할 수있는 작업을 수행하는 동시에 문제를 해결할 수있는 사람에게 문제를 알리는 것입니다. 실제로, 후자의 제약은 종종 직접적으로 만나기가 불가능하기 때문에 의심스러운 입력을 다루는 것이 가장 좋습니다.

프로토콜 디자인, 형식 지정 사양 또는 "언어"에 매우 도움이 될 수있는 한 가지 잠재적 이해되지 않은 항목의 네 가지 범주를 구분하는 방법을 사용하는 것입니다.

1. 이해되지 않으면 걸러 내야 할 것들.
2. 이해할 수없는 경우 무시해야하지만 그럼에도 데이터를 전달해야하는 경우에는 유지해야합니다 (아마도 데이터를 이해하지 못한 하나 이상의 단계를 통과했음을 나타내는 일종의 랩퍼).
3. 이해할 수없는 경우 경고를 생성해야하지만 데이터 복구 시도를 방해하지 않아야하는 것 (예 : 웹 페이지 내에서 유형을 알 수 없지만 파일 내에서 끝이 잘 정의 된 개체는 빨간색으로 렌더링 될 수 있음) 페이지의 나머지 부분이 렌더링되는 것을 막지 않고 "X"
4. 이해할 수없는 것은 다른 곳에서 심각하고 복구 할 수없는 문제가있을 수 있음을 나타냅니다 (예 : 남아있는 데이터가 압축되었다는 표시 및 필요한 압축 해제를 수행 할 수있는 것으로 이해되는 것).

모든 버전의 데이터 형식을 읽을 수있는 앱이 이후 버전을 준수하여 생성 된 항목에 적합한 범주를 인식 할 수 있도록 잘 정의 된 규칙을 갖는 것이 임시 호환성 측정에 쐐기를 시도하는 것보다 훨씬 나은 방법입니다. 나중에. 예를 들어, 파일 형식에 "태그 : 값"형식의 행이 있으면 태그의 첫 번째 문자가 해당 범주가 속하는 범주를 나타내도록 지정할 수 있습니다. 자동 무시 범주의 태그의 경우 첫 번째 문자는 태그가 유효한 것으로 예상되는 표준의 버전을 나타낼 수도 있습니다 (따라서 "자동 무시"태그가 버전 3에 있다고 주장하는 경우 표준 버전의 파서는 자동으로 무시하지만 버전 3 이상의 파서는 파싱 할 수 없다면 스 쿼크됩니다.

어쨌든 가장 중요한 것은 모호하거나 잘못 이해 된 데이터를 잘못된 데이터로 변환하지 않는 것입니다. 어떤 경우에는 모호한 데이터의 전파를 거부하는 것이 좋을 수도 있지만, 다른 경우에는 수신자가 모호하지 않은 것으로 간주 할 경우 수신 한대로 정확하게 전파하는 것이 좋습니다. 완전히 악한 것이 아니라면 정말 위험한 것은 다음과 같이 날짜 목록을 변환하는 등 다양한 가정을 사용하여 데이터를 변환하는 것입니다.

01/12/12
12/13/12
99/12/12

같은 날짜 목록으로

2012-01-12
2012-12-13
1999-12-12

잘못 입력 한 날짜가 몇 개인 목록이 있더라도 원래 형식의 목록을 제공 한 사람이 올바른 형식을 결정하고 추가 연구를 위해 모호한 값을 표시 할 수 있습니다 (다른 레코드를 확인하는 등). ) 그러나 후자의 형식으로 날짜를 렌더링하면 절망적으로 그리고 회복 불가능하게 날짜가 깨질 것입니다.

내 UI 경험은 대부분 데스크톱 시스템에서 나옵니다. 웹 사이트는 다르지만 데스크탑 시스템에 문제가 될 수있는 몇 가지 사이트가 있습니다. 그러나 가치가있는 것에 대해 :

오류 메시지가 가장 마지막 수단이어야한다는 것을 알았습니다. 이상적인 시스템은 전혀 없을 것입니다. 가장 좋은 방법은 처음부터 잘못된 항목을 허용하지 않는 것입니다. 사용자가 몇 달 드롭 다운 목록에서 선택하면 "녹색"을 입력 할 수 없습니다. 그는 회색 버튼을 누를 수 없습니다.

다음으로 할 일은 나쁜 데이터를 받아들이는 것입니다. 한 달 동안 일일 판매 히스토그램을 표시한다고 가정 해보십시오. 사용자 입력 후 그래프는 1 세기를 커버하고 1 세기 막대는 다른 것보다 10 배 높습니다. 사용자는 이제 자신이 잘못한 것을 알고 있으며, 어떤 메시지가 그에게 말할 수있는 것보다 자신이 잘못한 것에 대해 더 많이 알고 있습니다. 예를 들어 마우스를 드래그하여 항목이 그래픽 인 경우 이러한 종류의 피드백은 여전히 ​​작동하며 매우 중요합니다. 많은 입력이 유효하지 않을 수 있지만이 방법을 사용하면 사용자는 각 마우스 위치의 결과에 대한 즉각적이고 상세한 피드백을받습니다.

그러나 사용자가 버튼을 누를 수없는 이유 를 알아야 하는 경우가 있습니다. 그리고 (이 경우 어쩔 수 없다 이다 알려주세요)하지만 버튼을 ungray하고, 그가 그것을 클릭 할 때, 그에게 버튼을 순간에 작동하지 않는 이유에 대한 좋은 설명을 제공합니다.

성명서는 인터넷을 통해 정보를 보내는 것에 관한 것입니다. 인터넷을 통해 정보를 전송하는 것 중 하나는 항상 대상에 도달하거나 조각난 것이 아니라는 것입니다.

여기서 놓친 것, 실패의 결과는 무엇입니까?

웹 페이지를 표시 하시겠습니까? 나쁜 입력을 견딜 수 있도록 최선을 다해야합니다. 선택 사항은 가능한 것을 표시하거나 오류를 발생시키는 것입니다. 후자의 과정은 사용자에게 아무것도 제공하지 않으므로 사용자에게 완전히 쓸모없는 결과를 제공하기 때문에 최후의 수단이어야합니다.

반면 Minuteman III의 목표를 요구하는 경우 잠재적으로 모호하기 때문에 "Moscow"를 입력으로 거부합니다.