Друзья, не подскажите что за значения в POST http запросе

при git push origin [TAG_NAME]?

Вопрос, конечно, интересный. Вы какую-то проблему решаете или просто исследуете реквесты-респонсы гита?

molecrp
Всего понемногу) Вообще проблема есть на этапе изм...

Помимо доков (которые могли устареть или просто не быть обновленными) можете чекнуть сорцы гита. Или попробовать развернуть гит-сервер вручную, чтоб из схемы исключить гитлаб, а то вдруг это его какие-то специфичные заморочки.

Да, я тоже так думаю. Если даже не гитлаб, то может быть cloudflare, короче, я отпишусь, если будет что-то

Также помимо плейнтекста в реквестах-респонсах могут быть (или должны быть) бинари. А вообще гит работает же по https/ssh, и мне неясно, кто и почему у вас меняет шифрованный трафик.

Чтобы не было проблем на этапе общения с прокси поставил git config --global http.sslVerify false Или я вас неправильно понял?

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

Лучше будет сказать, что моя цель - не добиться работы гита, а скорее добиться пропуска одного измененного со стороны моего клиента запроса без каких-либо ошибок на стороне сервера. Я не уверен, но сколько я не работал с шифрованным трафиком - изменения текстовых данных запроса не должны отражаться на его шифрованной части. В POST запросе выше я изменил название с tag6 на tag7, но в body запроса содержится шифрованная часть и возможно эта часть как-то конфликтует с внесенными мною изменениями - но и тут я возможно чего-то не понимаю.

А, то есть таки протокол исследуете. Тут я не помогу. Разве что предложил бы проверить идемпотентность запросов, отправив чисто тег без новых коммитов, после чего удалив его и отправив снова. И так же с тегом с другим именем.