golang: HTTP; Массивы

Что за url.Values?

Все, нашел. https://golang.org/pkg/net/url/#Values

Нет, не должно быть. Это тебе не рельсы, где фреймворк за тебя все делает, и еще и кофе нальет.

http://play.golang.org/p/b8-QTlewYr

package main

import "fmt"
import "net/url"

func main() {
	var url, err = url.ParseQuery("http://google.ru?a=1&a=2&b=3")
	
	if err != nil {
		panic(err)
	}
	
	fmt.Println(url.Get("a"))
}

В PHP индексы - не обязательно числа: «a[blabla]»: «foobar»

Покажи HTTP-запрос. Сдаётся мне, что у тебя кривая страница шлёт всё в таком виде: a[0]=Aborted&a[1]=Aborted и тд. В Go всё работает нормально.

У тебя тут две ошибки. Во-первых надо передавать Query, а не URI. Т.е. надо передавать «a=1&a=2&b=3». Во-вторых в документации написано, что Get возвращает первое значение, чтобы получить все значения, надо использовать map напрямую. Вот правильный код:

package main

import "fmt"
import "net/url"

func main() {
	var url, err = url.ParseQuery("a=1&a=2&b=3")
	
	if err != nil {
		panic(err)
	}
	
	fmt.Println(url["a"])
}

который выводит [1 2]

http://play.golang.org/p/uVZusygS0h

Это deadbeef присылает.

Короче я всё-таки погуглил. Оказалось, что это не стандартизовано, потому имеем, что имеем:

a=v1&a=v2&a=v3

a[]=v1&a[]=v2&a[]=v3

a[0]=v1&a[1]=v2&a[2]=v3

Все варианты имеют право на жизнь и много где используются, но в go почему-то решили, что единственно верный — это первый вариант. Хотя как по мне, должны учитываться все возможные варианты.

Как по мне, тебе стоит обратно вернуться на раби, или откуда ты там.

Это ещё почему?

У тебя несовместимый с Go майндсет, и ты не собираешься его изменять, судя по всему.

Это тебе не рельсы
тебе стоит обратно вернуться на раби

У вас рубянка же, срочно вернитесь в палату. x

А что тогда go-way? Вот конкретно в этом случае, по-твоему, я должен сам решать эту проблему вместо того, чтобы положиться на стандартную библиотеку, верно? Но ведь это далеко не единичный случай. Существует огромное кол-во клиентов, которые могут представлять массивы так, как им вздумается. Можешь объяснить, почему эта проблема не касается стандартной библиотеки?

В PHP с этим считаются (правда как всегда через жопу :3), а вот Python, насколько я понял, также, как и в go сделано. В рубях не знаю, нет возможности проверить.

В HTTP параметры передаются в виде имя=значение. Вот и вся история. Ты передаёшь имя «a[0]». Go тебе его сохраняет в неизменном виде. Имхо, в любой вменяемой HTTP библиотеке будет ровно то же самое. Я не представляю, кому пришло в голову передавать множественные параметры таким странным и ненатуральным образом. Давай передавать параметры в виде

i=0&a[i++]=Some&a[i++]=Another&a[i++]=Value

В HTTP параметры передаются в виде имя=значение. Вот и вся история.

К сожалению не вся, наивная стандартная библиотека годится только для хеллоуволдов. А как жи хваленые «батарейки»? Даже в твоей жабке парсер адекватный.

Это тебе не рельсы, где фреймворк за тебя все делает, и еще и кофе нальет.

И что, считаешь это плохо? Забавляют микро-шизики, придумавшие писать на недоязычке в стиле хардкорного CGI 20-летней давности.

Напиши пакет с функцией для парсинга этого говна и выложи на жыдхаб.

В вк видел такой же подход.

ствует огромное кол-во клиентов, которые могут представлять массивы так, как им вздумается. Можешь объяснить, почему эта проблема не касается стандартной библиотеки?

В вопросе содержится ответ.

Тебе имя параметра не нравится, или что? Какое дело http протоколу, как там дальше, в приложении, они будут использоваться?

Никакого дела. И библиотеке, которая парсит параметры, тоже никакого дела до того, как ты их используешь.

И тогда, почему это плохо, когда пхп разбирает определенные параметры в массив?

http://blog.parse.com/learn/how-we-moved-our-api-from-ruby-to-go-and-saved-ou...

The hardest part of the rewrite was dealing with all the undocumented behaviors and magical mystery bits that you get with Rails middleware. Parse exposes a REST API, and Rails HTTP processing is built on a philosophy of “be liberal in what you accept”. So developers end up inadvertently sending API requests that are undocumented or even non-RFC compliant … but Rails middleware cleans them up and handles it fine.

So we had to port a lot of delightful behavior from the Ruby API to the Go API, to make sure we kept handling the weird requests that Rails handled. Stuff like doubly encoded URLs, weird content-length requirements, bodies in HTTP requests that shouldn’t have bodies, horrible oauth misuse, horrible mis-encoded Unicode.

За применение рельсов и фреймворков с подобной им магией в чем-либо сложнее бложика надо расстреливать.

ты сам то хоть для чего-то серьёзного применял хоть что-то, а?

анус о 500-ку порвёшь потому что

Я не представляю, кому пришло в голову передавать множественные параметры таким странным и ненатуральным образом.

Автору PHP.

да ну, глупости это все

в чем состоит «магия» такой интерпретации данных, осуществляемой _внутри_ приложения? и почему кого-то, кроме непосредственно разраба, вообще волнует, что там происходит и какие структуры применяются в этом ЧЯ?

Потому что для передачи массива используется общепринятая нотация «a=1&a=2&a=10&a=bla». А в PHP придумали свою бредовую нотацию. И пытаются тащить её в другие языки.

Это не только в php так. deadbeef тому подтверждение.

что за deadbeef?

https://github.com/Alexey-Yakovenko/deadbeef

Ну и какое же значенине в итоге примет a? И почему именно такое?

Вторую, неудобную часть вопроса ты проигнорировал, потому правильный ответ на него «так сделано в go», и не откуда не слндует, что 1.это наиболее очевидная интерпретация и 2.что другие делают неправильно.

За применение рельсов и фреймворков с подобной им магией

Причем тут магия? Фреймворк просто либерально относится к входящим данным, пытаясь прожевать любые какашки. Это абсолютно нормальное и правильное поведение (попробуй поюзать браузер, признающий только strict html, например). Когда ты запилишь на го «что-то сложнее бложика», у тебя будет дохрена такой магии, я гарантирую это.

1.это наиболее очевидная интерпретация и 2.что другие делают неправильно.

насрать, в общем-то

Это абсолютно нормальное и правильное поведение

Ой ли.

попробуй поюзать браузер, признающий только strict html, например

Просто исторически так сложилось, что браузеры принимают всякое говно от девятиклассника Васи, это ничего не доказывает.

Следует изначально четко очертить круг возможных значений и посылать индусню куда подальше при малейшем нарушении протокола.

Следует изначально четко очертить круг возможных значений и посылать индусню куда подальше при малейшем нарушении протокола.

Если бы так было на самом деле. Как я уже отметил выше, в RFC ничего не говорится о повторяющихся элементах в запросе. А значит решение этой проблемы ложится на разработчиков. Добавление квадратных скобок с возможным индексированием встречается очень часто независимо от используемых инструментов. А потому, ИМХО, не вижу ничего плохого, если это будет реализовано в стандартной библиотеке.

так о чем и речь

осталось только объяснить, почему один запрос («a[1]=q&a[2]=w») — это нарушающее протокол говно, а другой («a=q&a=w») — Истина, Данная Нам Свыше

ну, или понять, что «индусня» здесь только ты и последовать собственному совету.

почему один запрос («a[1]=q&a[2]=w») — это нарушающее протокол говно, а другой («a=q&a=w») — Истина, Данная Нам Свыше

Потому что первый как-то посимпатичнее

Добавление квадратных скобок

Во-первых, никак не нарушает протокол.

Во-вторых, обеспечивает уникальность имен параметров.

В-третьих, как оценил проблему другой анонимус — насрать, в общем-то. Приложение может интерпретировать строку запроса вобще как угодно, например '?a=q&a=w' => var q='a'; var w='a';

Мань, я не собираюсь объяснять выдуманные тобой вещи.

А я вижу.

Возьми и сам сделай себе middleware, если так жжет

штаа?

golang: HTTP; Массивы (комментарий)

забазарщик-неответчик?

У анонимной плесени еще с логикой проблемы, как мило.

ну если ты скан паспорта не выклаыдвал, то да, у анонимной плесени с логикой проблемы

Возьми и сам сделай себе middleware

Девиз микро-задротов, ггг. По факту это и приходится делать, потому что в вашем го нихера нет, и самые базовые вещи реализованы с детсадовской наивностью. Ещё лет пять будете блуждать по граблям, пока наконец не высрете очередную уебищную недорельсу.

Как скажешь.