Официальная позиция дублированных ключей запроса HTTP GET
Хм... никакой TCL
proc factorial {n} {
if { $n == 0 } { return 1 }
return [expr {$n*[factorial [expr {$n-1}]]}]
}
puts [factorial 6]
, Но конечно который не работает на проклятое для больших значений n...., мы можем добиться большего успеха с tcllib!
package require math::bignum
proc factorial {n} {
if { $n == 0 } { return 1 }
return [ ::math::bignum::tostr [ ::math::bignum::mul [
::math::bignum::fromstr $n] [ ::math::bignum::fromstr [
factorial [expr {$n-1} ]
]]]]
}
puts [factorial 60]
Взгляд на все они] в конце. Это - практически LISP!
я оставлю версию для значений n> 2^32 как excersize для читателя
3 ответа
Там нет спецификации на это. Вы можете делать то, что вам нравится.
Типичные подходы включают в себя: первый заданный, последний заданный, массив всего, строка-соединение с запятой-всего.
Предположим, исходный запрос:
GET /blog/posts?tag=ruby&tag=rails HTTP/1.1
Host: example.com
Кроме того, существуют различные варианты того, что должен выдавать request.query ['tag'] , в зависимости от языка или структуры:
request.query['tag'] => 'ruby'
request.query['tag'] => 'rails'
request.query['tag'] => ['ruby', 'rails']
request.query['tag'] => 'ruby,rails'
Большинство (все?) фреймворков не дают никаких гарантий, поэтому предположим, что они будут возвращены в случайном порядке.
Всегда выбирайте самый безопасный подход.
Например, интерфейс java HttpServlet: ServletRequest.html # getParameterValues
Даже метод getParameterMap не упоминает о порядке параметров (на порядок итератора java.util.Map тоже нельзя полагаться)
Обычно повторяющиеся значения параметров, такие как
http://example.com/page?field=foo&field=bar
, приводят к единственному параметру queryString, который является массивом:
field[0]=='foo'
field[1]=='bar'
Я видел такое поведение в ASP, ASP.NET и PHP4.