> On Jan. 27, 2015, 1:46 a.m., wdoekes wrote: > > > 1) Server: Asterisk/<version > > > 2) Server: JohnMcClane > > > 3) Server: > > > > Any particular reason why we don't simply omit the header in the third case? > > > > The ABNF at 14.38 here [1] says: > > Server = "Server" ":" 1*( product | comment ) > > that is, one or more, not zero or more > > > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html > >
I went back and forth with this during development. On one hand, the RFC you called out specifies that all header fields have some value. But, on the other hand, the question kept bugging me, "would implementing a configuration property in this way, where blank had a different meaning than all other values, violate the principle of least astonishment?" Even though I realized that the former was technically the correct way to implement this, ultimately, I went with the latter as my reasoning, so as not to create unexpected behavior. ***However, it can be argued that failing to honor the RFC would equally create astonishment. And, since this is technically the correct way to implement this feature, the behavior has been modified as follows: This test verifies that the HTTP server correctly reports the expected name through the [Server] header field in all HTTP responses. It uses three instances of Asterisk to test the three possible logic paths: 1) No configuration was provided 2) A non-empty/non-null value was provided through the new configuration property [servername] 3) An empty/null value was provided through the new configuration property [servername] For clarity, consider this example for the possible outcomes as described above, respectively: 1) There was nothing configured for [servername]. 2) The user configured a non-empty value for [servername] (e.g. servername="JohnMcClane") 3) The user configured an empty/null value for [servername] (e.g. servername="") The HTTP server is expected to create the [Server] header field as follows, respectively: 1) Server: Asterisk/<version> 2) Server: JohnMcClane 3) In case #3, the [Server] header field will be omitted from HTTP response headers. - Ashley ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4377/#review14306 ----------------------------------------------------------- On Jan. 26, 2015, 9:27 p.m., Ashley Sanders wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4377/ > ----------------------------------------------------------- > > (Updated Jan. 26, 2015, 9:27 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24316 > https://issues.asterisk.org/jira/browse/ASTERISK-24316 > > > Repository: testsuite > > > Description > ------- > > Currently, all responses from the Asterisk HTTP server contain a [Server] > header that identifies Asterisk and its version (e.g. > "Server:Asterisk/<version>", where <version> is the currently running version > of Asterisk). The preferred behavior is to allow the user to configure an > alternate name to use for the value returned in the [Server] header for HTTP > responses (e.g. "Server:SomeSuperAwesomeServerName"). > > This patch to the Asterisk source provides a new configuration property, > [servername], in http.conf, that gives users the ability to modify the value > that Asterisk uses when identifying itself. > > This test verifies that the HTTP server correctly reports the expected name > through the [Server] header in all HTTP responses. It uses three instances of > Asterisk to test the three possible logic paths: > 1) No configuration was provided > 2) A non-empty/non-null value was provided through the new configuration > property [servername] > 3) An empty/null value was provided through the new configuration property > [servername] > > For clarity, consider this example for the possible outcomes as described > above, respectively: > 1) There was nothing configured for [servername]. > 2) The user configured a non-empty value for [servername] (e.g. > servername="JohnMcClane") > 3) The user configured an empty/null value for [servername] (e.g. > servername="") > > The HTTP server is expected to create the [Server] header as follows, > respectively: > 1) Server: Asterisk/<version > 2) Server: JohnMcClane > 3) Server: > > ***Note*** This is the test. It is only the test. You can find the review for > the Asterisk source at: https://reviewboard.asterisk.org/r/4374/ > > > Diffs > ----- > > ./asterisk/trunk/tests/tests.yaml 6339 > ./asterisk/trunk/tests/http_server/tests.yaml PRE-CREATION > ./asterisk/trunk/tests/http_server/servername/test-config.yaml PRE-CREATION > ./asterisk/trunk/tests/http_server/servername/run-test PRE-CREATION > ./asterisk/trunk/tests/http_server/servername/configs/ast3/http.conf > PRE-CREATION > ./asterisk/trunk/tests/http_server/servername/configs/ast2/http.conf > PRE-CREATION > ./asterisk/trunk/tests/http_server/servername/configs/ast1/http.conf > PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4377/diff/ > > > Testing > ------- > > > Thanks, > > Ashley Sanders > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
