OpenPNE 3

更新履歴 c50557e901d77633db2b1812b2c7041a3ca045c5 で適用されました。

curlコマンドではなぜか404エラーとなってしまうため、telnetにて確認しました。

telnet sns.example.com 80

GET /api.php/feeds/member/1 HTTP/1.1
Host: sns.example.com

HTTP/1.1 200 OK

=== (省略) ===

401 Unauthorized

• 修正前のコードにも言えることですが、自前で header() 関数をコールするよりも sfWebResponse::sendHttpHeaders() をコールする形にするのが望ましいです。
  • その場合、 Content-Type ヘッダが新たに出力されるようになると思われます。この値は text/html がデフォルトです。 OpenPNE Web API、 Google Data API、 Atom Publishing Protocol (RFC 5023) の仕様書のいずれにもエラー時のレスポンスの Content-Type についての記述がありません。 text/plain を採用するのが妥当かもしれませんね。
• レスポンスボディへのステータスコードの出力が削除されていますが、これはなぜでしょうか。 RFC 5023 の "5.5. Use of HTTP Response Codes" http://tools.ietf.org/html/rfc5023#section-5.5 には、以下のような記述があります。
  

     Implementers are asked to note that according to the HTTP
     specification, HTTP 4xx and 5xx response entities SHOULD include a
     human-readable explanation of the error.
  
     （拙訳）HTTP 仕様に基づき、 HTTP 4xx と 5xx のレスポンスエンティティは human-readable なエラーの説明を含むべき (SHOULD) であることに注意することが実装者に求められている。
  

  
  要求レベルが RFC 2119 で定められた SHOULD であるので、この仕様に反した実装をするからには、仕様を退けるべき妥当な理由が必要だと考えます。
  • また、この変更は、仕様に反しているだけでなく、互換性の観点からも問題があると考えています。この修正以前はステータスコードからエラーであるかどうかの判断がおこなえなかったわけですから、レスポンスボディからステータスコードを得て、エラーについての判別をおこなっていた可能性が充分に考えられます。これのレスポンスボディは利便のための配慮で、 RFC 5023 においてさえも明示された仕様ではないため、この変更をおこなうことにより意図した挙動をおこなわなくなるようなアプリケーションは、そのアプリケーション側で修正をおこなうべきと言えるとは思います。とはいえ、特段理由がないのならば後方互換性を保つような実装を維持するのが妥当だと考えます

更新履歴 6a717dbea7857a13095033077f68f6416d180ec3 で適用されました。

テストOKです。