2017-02-26 17 views
0

나는 PSR-7UriInterface의 구현 작업을하고 있으며 구현시 일부 구성 요소에 대해 InvalidArgumentException을 throw해야하는시기에 대해서는 약간의 혼란이 있습니다.PSR-7 UriInterface - 유효하지 않은 구성 요소 백분율 인코딩

예 : UriInterface::withPath specifies throwing such an exception given an invalid path하지만 "구현으로 올바른 인코딩이 보장되므로"사용자는 인코딩 된 경로 문자와 디코딩 된 경로 문자를 모두 제공 할 수 있습니다.

/** 
* ... 
* 
* Users can provide both encoded and decoded path characters. 
* Implementations ensure the correct encoding as outlined in getPath(). 
* 
* @param string $path The path to use with the new instance. 
* @return static A new instance with the specified path. 
* @throws \InvalidArgumentException for invalid paths. 
*/ 

인코딩을 관리해야하는 구현은 나머지 사양에서 다루어집니다.

구현시 올바른 인코딩이 보장되므로 구현 사용자가 달리 유효하지 않은 문자를 withPath와 같은 함수에 전달할 수 있으므로 예외를 트리거하는 것이 아니라 올바르게 인코딩됩니다.

withPath에 문자열이 전달되지 않은 경우 해당 값이 Guzzle's interpretation of the specification 인 것처럼 보이는 경우에만 InvalidArgumentException이 발생한다고 생각할 수 있습니다.

PHP's brief introduction of InvalidArgumentException의 엄격한 읽기는 이런 종류의 "엄격한 타이핑"해석을 피하는 것처럼 보일 수 있지만, PHP-FIG가 다른 점을 염두에두고 있는지, 특히 URI 구문의 복잡성을 고려하면 궁금합니다. 일반적으로

withPath와 같은 UriInterface 메서드가 문자열을 전달하는 경우 예외를 throw해야하는 시나리오가 있습니까?

답변

1
내가 아는

, 당신의 질문은

귀하의 가정이 완전히 옳다 조금 오래된 :-)입니다! 부분에 대해

:

사용자 모두 인코딩 및 디코딩 경로의 문자를 제공 할 수 있습니다.
구현은 getPath()에 설명 된대로 올바른 인코딩을 보장합니다.

이것은 "잘못된 경로"(@throws 태그에 설명되어 있음)와는 아무런 관련이 없습니다. 귀하가 합당하게 주장한 바에 따르면 사용자는 적절하게 인코딩 된 문자와 디코딩 된 문자를 의 의미로- 백분율로 인코딩하여 제공 할 수 있습니다. 예 : 일부 인코딩되지 않은 문자는 백분율로 인코딩되고 다른 문자는 그렇지 않습니다. 원칙적으로, 인코딩 방식은 다음과 같습니다 한편

Percent-encode all URI path characters, except: 

- the unreserved characters, 
- the reserved characters of the subset "gen-delims", 
- the reserved characters of the subset "sub-delims", 
- the already percent-encoded characters. 

예외 - InvalidArgumentException이 - 다음과 같은 매개 변수 '무효 상황에서 발생합니다 :

  • withScheme : 문자열이 아닌이며 허용되는 목록의 일부가 아닙니다 스키마;
  • withHost :는 문자열이 아닙니다.
  • withPort : 숫자가 아니거나 정수입니까?) 범위 내에 있지 않다 [1, 65535];
  • withPath :는 문자열이 아닙니다.
  • withQuery :는 문자열이 아닙니다.
  • withFragment :는 문자열이 아닙니다.

    • 가 비어있는 문자열이 설정되지 않은 :

    그리고 마침내

  • 는 특별한 치료는 URI의 ( $uri가) (옵션 NULL) 생성자의 인수로 전달 된 문자열을 수신

... URI 문자열 매개 변수에 parse_url을 호출 한 결과 URI 부분 배열 (여기에서 thr 아야 UnexpectedValueException) : 나는 UriInterface 구현 내부의 모든 예외를 던지는 상황을 나열했습니다

$uriParts = parse_url($uri); 

if ($uriParts === FALSE) { 
    throw new \UnexpectedValueException('URI could not be parsed!'); 
} 

참고.