Asciinema: Permintaan buruk untuk mengunggah rekaman> 4kb di bawah CentOS (Python 3.4)

Terjadi juga untukku. Menggunakan ZSH tapi bukan OMZ.

$ zsh --version
zsh 5.3.1 (x86_64-pc-linux-gnu)
$ asciinema --version
asciinema 1.4.0

tmpw6byrbv8-asciinema.json

Saya menemukan bahwa jika saya mengubah URL API dari HTTPS ke HTTP semuanya berfungsi dengan baik.

Saya telah mengubah konfigurasi penyeimbang beban kemarin, jadi ini mungkin terkait.

Saya dapat mereproduksi ini di Centos 7 Vagrant VM. Saya rasa ini ada hubungannya dengan penyeimbang beban Brightbox (dengan penghentian SSL, sertifikat Let's Encrypt otomatis) yang kami gunakan sejak kemarin.

@andyone @ThiefMaster bisa coba sekarang? Saya mungkin telah menyelesaikannya.

masih mendapatkan 400

Saya pikir ini adalah masalah terkait OpenSSL. Mengirim data dengan curl tidak masalah karena curl menggunakan NSS (Layanan Keamanan Jaringan) untuk bekerja dengan SSL / TLS.

dengan load balancer Brightbox

Ini adalah solusi berbasis nginx?

@andyone Saya pikir load balancer Brightbox menggunakan Haproxy.

Saya dapat mereproduksi ini secara konsisten. Saya membuat Vagrantfile dan instruksi: https://github.com/sickill/bb-lb-400

@andyone masalahnya bukan pada baris khusus ini dalam rekaman Anda, tetapi ukuran keseluruhan dari file json yang diunggah.

Saya membuat proxy https://ascii.kaos.io berdasarkan webkaos (ditingkatkan nginx dengan BoringSSL) dengan konfigurasi ini . Rekaman saya dan @ThiefMaster berhasil diunggah melalui proxy ini.

Inilah yang saya ketahui sejauh ini:

Permintaan HTTP baik-baik saja melalui penyeimbang beban Brightbox, tetapi permintaan HTTPS memberikan 400 Permintaan Buruk
untuk permintaan di mana permintaan tubuh lebih besar dari sekitar 4KB.

Hal yang menarik adalah kami mendapatkan 400 untuk HTTPS di bawah CentOS. HTTPS di bawah macOS berfungsi dengan baik. (HTTP berfungsi dengan baik di mana saja).

Saya melihat lebih dalam, mencoba mencari tahu di mana perbedaannya. Saya menggunakan tcpdump untuk melihat permintaan pada CentOS dan macOS (HTTP, mengasumsikan permintaan itu sendiri diformat sama seperti di bawah HTTPS).

Satu-satunya perbedaan adalah 2 baris kosong sebelum body pada macOS, 1 baris kosong pada CentOS (mungkin karena versi urllib yang sedikit berbeda yang disertakan dengan Python 3 pada OS ini):

CentOS:

POST /api/asciicasts HTTP/1.1
Accept-Encoding: identity
User-Agent: asciinema/1.4.0 CPython/3.4.5 Linux/3.10.0-514.16.1.el7.x86_64-x86_64-with-centos-7.3.1611-Core
Authorization: Basic <61 bytes of base64 encoded credentials>
Content-Length: 13582
Content-Type: multipart/form-data; boundary=c3f4e35afa4a4ce6b65b6420da09b46e
Connection: close
Host: asciinema.org

--c3f4e35afa4a4ce6b65b6420da09b46e
Content-Disposition: form-data; name="asciicast"; filename="asciicast.json"
Content-Type: application/json

<about 13 kb of json>

macOS:

POST /api/asciicasts HTTP/1.1
Accept-Encoding: identity
Content-Length: 13582
Host: asciinema.org
User-Agent: asciinema/1.4.0 CPython/3.6.1 Darwin/16.5.0-x86_64-i386-64bit
Content-Type: multipart/form-data; boundary=71d5b757e9d1451b9540dc286f74207d
Authorization: Basic <61 bytes of base64 encoded credentials>
Connection: close


--71d5b757e9d1451b9540dc286f74207d
Content-Disposition: form-data; name="asciicast"; filename="asciicast.json"
Content-Type: application/json

<about 13 kb of json>

Untuk melihat bagaimana pengaruhnya terhadap hal-hal saya untuk sementara mengubah "Minta ukuran buffer" pada LB dari 4096 (default) menjadi 8192 (maks) dan tiba-tiba mulai berfungsi dengan baik di mana-mana (semua OS, HTTPS), yay!

Saya tidak terlalu yakin ini adalah solusi pamungkas karena dengan ukuran buffer 4096 ini benar:

• Saya dapat membuat permintaan POST dengan ukuran 3MB tanpa masalah
  HTTPS di macOS
• Jadi saya berasumsi ukuran buffer ini untuk header dan bukan badan permintaan (ini dikonfirmasi oleh John dari Brightbox)
• Saya dapat membuat permintaan POST dengan tubuh <4KB tanpa masalah
  HTTPS di CentOS
• Saya TIDAK dapat membuat permintaan POST dengan> 4KB body melalui HTTPS di CentOS
• Di atas bertentangan dengan asumsi saya tentang buffer yang hanya berlaku untuk header ...
• Header permintaan berukuran kecil (~ 330 byte) dalam semua kasus

Ketika saya menabrak "request buffer size" menjadi 8192 ukuran tubuh dan protokolnya
tidak masalah dan semuanya berfungsi dengan baik. Saya bertanya-tanya apakah dengan menabrak
ke 8192 Saya hanya mengulur waktu (membuat lebih sedikit orang terpengaruh) atau ini
memecahkan masalah sepenuhnya (jika demikian, lalu mengapa?).

Saya menghubungi Brightbox tentang ini, semoga mereka bisa menjelaskan apa yang terjadi.

Perbarui kembali ukuran buffer 8192 di sisi Brightbox: dengan nomor ini ini berfungsi untuk saya di bawah CentOS tetapi masih tidak berfungsi untuk @ThiefMaster .

Ops, maaf.

Sebelum saya memasukkan lalu lintas melalui Brightbox LB, saya menghentikan SSL di Nginx dan semuanya berfungsi dengan baik selama bertahun-tahun. Jika ia bekerja dengan proxy @andyone berdasarkan Nginx maka ia mungkin menyarankan Nginx lebih "memaafkan" tentang pemformatan permintaan, sementara Haproxy lebih ketat, dan klien asciinema memformat permintaan secara tidak benar (untuk standar Haproxy) di bawah Python 3.4 (dan urllib, yang lebih tua dari 3.6.1 yang saya gunakan di mac).

Saya dapat memeriksanya nanti dengan Haproxy, tetapi versi saya dibuat dengan LibreSSL, bukan OpenSSL.

Teori saya saat ini adalah ini:

Satu baris baru sebelum header dan isi ini tidak cukup bagi LB untuk menyelesaikan membaca header (ia mengharapkan 2 baris baru), dan terus membaca semua data di bawahnya sebagai header, menghitung byte, yang pada akhirnya melebihi ukuran maksimal untuk header. Jika LB memiliki beberapa variabel seperti bytes_read (byte dibaca dari socket), LB memeriksa nilainya setelah menyelesaikan membaca header, dan kemudian lagi setelah membaca body. Jika Anda mengunggah file <4kb maka tidak pernah melewati batas 4kb untuk header, dan jika Anda mengunggah> 4kb itu melebihi itu.
(dan ini hanya terjadi di bawah HTTPS)

Tidak tahu apa masalahnya, hanya berpikir keras 😀

Memperbarui kode sumber sehingga menambahkan baris baru, diperiksa di bawah CentOS dan masih gagal. Jadi teori di atas salah.

Ini berfungsi di bawah CentOS dengan HTTPS:

curl -v -X POST -u $USER:api-token https://asciinema.org/api/asciicasts -F [email protected]

* About to connect() to asciinema.org port 443 (#0)
*   Trying 109.107.38.233...
* Connected to asciinema.org (109.107.38.233) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*   subject: CN=asciinema.org
*   start date: Jun 07 09:12:00 2017 GMT
*   expire date: Sep 05 09:12:00 2017 GMT
*   common name: asciinema.org
*   issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
* Server auth using Basic with user 'vagrant'
> POST /api/asciicasts HTTP/1.1
> Authorization: Basic <...hidden...>
> User-Agent: curl/7.29.0
> Host: asciinema.org
> Accept: */*
> Content-Length: 5658
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=----------------------------6ca3f3de6469

Jadi mungkin SSL lib yang digunakan oleh Python berbeda dari curl dan masalahnya ada di SSL-land?

Aku pikir begitu. Python menggunakan OpenSSL, curl menggunakan NSS.

@andyone sertifikat untuk ascii.kaos.io bukan Let's Encrypt?

RapidSSL SHA256denganRSA

Biasanya saya akan mengatakan CentOS kehilangan sertifikat root untuk Let's Encrypt (atau sesuatu seperti itu 😊), tetapi koneksi SSL sedang dibuat dan kesalahannya ada pada level protokol HTTP (400 Permintaan Buruk) jadi ... 👐

Jika sertifikat root untuk Let's Encrypt hilang, itu tidak akan berfungsi bahkan dengan curl.

Penyeimbang beban (Brightbox) kami memang menggunakan haproxy. HTTP RFC dan dokumen haproxy menyatakan bahwa satu CRLF diperlukan untuk memisahkan header dari badan:

https://github.com/haproxy/haproxy/blob/master/doc/internals/http-parsing.txt

Apakah mungkin Anda hanya mengirimkan CR atau LF di sini, bukan CRLF lengkap?

@sickill Ini adalah proxy pada HA-Proxy 1.7.5 dengan LibreSSL 2.5.0 - https://ascii-ha.kaos.io. Rekaman saya dan @ThiefMaster , dan over-4k.json dari repositori Anda berhasil diunggah melalui proxy ini.

@andy_yyah . Jadi, dapatkah Anda mengubah tune.bufsize (https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-tune.bufsize) menjadi 4096?

@ Johnl Saya memeriksa CRLF dan semuanya baik-baik saja di sini.

Saya tcpdump permintaan pada CentOS dan macOS lagi (melalui HTTP, sekali lagi, dengan asumsi muatan HTTP sama untuk HTTPS).

dump-centos.pcap.txt dan dump-mac.pcap.txt berisi tangkapan tcpdump ( tcpdump -s 0 dst port 80 -w dump-centos.pcap.txt ).
dump-centos-hex.txt dan dump-mac-hex.txt berisi dump berformat hex (melalui hexdump -C ).

dump-centos-hex.txt
dump-centos.pcap.txt
dump-mac-hex.txt
dump-mac.pcap.txt

Tampaknya di kedua OS ada CRLF yang digunakan untuk baris baru, dan ada satu baris kosong antara header dan isi.

Di CentOS kiri, di macOS kanan:

@sickill Config diperbarui. over-4k.json diunggah.

@andyone terima kasih atas pembaruannya. Tampaknya itu tidak menambahkan X-Forwarded-Proto header (karena URL rekaman yang dikembalikan adalah http:// ). Bisakah Anda menambahkan http-request set-header X-Forwarded-Proto https if { ssl_fc } ?

Ini konfigurasi saya:

frontend www-https
    bind 207.154.241.251:443 ssl crt /etc/ssl/private/kaos.pem
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    server asciinema-backend asciinema.org:80

Di mana saya harus menambahkan baris ini?

@andyone Saya pikir itu perlu masuk ke bagian backend (saya bukan ahli haproxy).

@andyone btw, saya

jangan lupa untuk terus maju juga. Ini harus mereplikasi pengaturan dengan cukup dekat, dengan cipher ssl juga:

    tune.bufsize 4096
    tune.ssl.default-dh-param 2048
    tune.maxrewrite 40

frontend www-https
    bind 207.154.241.251:443 ssl no-sslv3 crt /etc/ssl/private/kaos.pem ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    server asciinema-backend asciinema.org:80
    mode http
    option forwardfor
    option httplog

Saya mengubah konfigurasi menjadi ini, tetapi tidak berhasil:

    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option                  http-server-close
    option                  forwardfor
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

frontend www-https
    bind 207.154.241.251:443 ssl crt /etc/ssl/private/kaos.pem
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    http-request set-header X-Forwarded-Proto https
    server asciinema-backend asciinema.org:80

Klien masih mengembalikan tautan dengan http:// .

Saya selalu senang membantu meningkatkan layanan yang bermanfaat 😉.

@johnl Ini adalah konfigurasi lengkap, semua opsi yang diperlukan disetel di defaults dan global bagian:

    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    tune.bufsize 4096

    # SSL configuration
    tune.ssl.default-dh-param 2048
    ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
    ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option                  http-server-close
    option                  forwardfor
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

frontend www-https
    bind 207.154.241.251:443 ssl crt /etc/ssl/private/kaos.pem
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    http-request set-header X-Forwarded-Proto https
    server asciinema-backend asciinema.org:80

Jika konfigurasi haproxy @andyone sekarang sangat dekat dengan BB dan kami masih tidak dapat mereproduksi masalah tersebut, apakah masuk akal untuk mencoba dengan Let's Encrypt cert? Inilah salah satu perbedaan antara https://ascii-ha.kaos.io dan https://asciinema.org.

Inilah salah satu perbedaan antara https://ascii-ha.kaos.io dan https://asciinema.org.

Tidak. BB LB dapat dibangun dengan OpenSSL (Saya menggunakan LibreSSL).

Saya akan mencoba menambahkan sertifikat Let's Encrypt untuk https://ascii-ha.kaos.io.

Selesai - https://ascii.kaos.re
HA-Proxy 1.7.5 (w / LibreSSL 2.5.0) + sertifikat Let's Encrypt (dibuat oleh Certbot)
Konfigurasi:

    tune.bufsize 4096
    tune.ssl.default-dh-param 2048
    tune.maxrewrite 40

frontend www-https
    bind 207.154.241.251:443 ssl no-sslv3 crt /etc/ssl/private/ascii.kaos.re.pem ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
    reqadd X-Forwarded-Proto:\ https
    default_backend www-backend

backend www-backend
    server asciinema-backend asciinema.org:80
    mode http
    option forwardfor
    option httplog

Sepertinya semua berfungsi dengan baik. over-4k.json berhasil diunggah.

Saya tidak punya ide lebih lanjut untuk ini. Saya sedang mempertimbangkan untuk kembali ke instance Nginx saya sendiri untuk load balancing dan penghentian SSL 🤕

Saya mencoba meringkas ini menjadi satu perintah curl yang dapat mereproduksi masalah, tetapi belum berhasil, adakah yang bisa membantu?

Saya mem-posting badan 5k, dengan nama pengguna / kata sandi otentikasi menggunakan curl. Saya menggunakan penyeimbang beban Brightbox dengan backend server web netcat, jadi saya dapat melihat teks permintaan mentah. Itu selalu berhasil - tidak bisa membuatnya memicu respons permintaan yang buruk.

Jika ini ditolak oleh penyeimbang beban, saya seharusnya tidak memerlukan contoh nyata dari aplikasi di backend, karena seharusnya tidak pernah sejauh itu - jadi kita harus dapat mereproduksi ini dengan curl dan tanpa aplikasi.

Saya sudah mencoba curl di ubuntu dan centos7, dan dengan openssl khusus (perhatikan Anda dapat menentukan perintah --engine ke curl untuk memilih lib sslib mana yang akan digunakan. Centos7 curl binari dibangun terhadap sebagian besar opsi)

@ Johnl terima kasih telah melihat ini.

Masuk akal untuk menggunakan netcat sebagai backend untuk pengujian 👍

curl setara untuk asciinema upload over-4k.json kurang lebih ini:

curl -v -X POST -u test:uuid4 https://asciinema.org/api/asciicasts -F [email protected]

(ganti uuid4 dengan hasil python3 -c 'import uuid; print(uuid.uuid4())' )

Dan memang bekerja dengan curl ...

Saya membandingkan tcpdump asciinema upload dan ikal di atas dan tidak ada apa pun pada tingkat protokol HTTP yang tampak mencurigakan bagi saya. Namun, beberapa frame tcp muncul di lokasi yang berbeda (mungkin lebih banyak / sedikit data yang dikirim / muat di setiap paket tcp).

Saya menangkap permintaan HTTP (ke http://asciinema.org) dengan tcpflow di CentOS 7 VM:

sudo tcpflow -p -C -i eth0 port 80 >tcpflow-req.txt

Kemudian di shell lain (di VM yang sama) jalankan:

ASCIINEMA_API_URL=http://asciinema.org asciinema upload /vagrant/over-4k.json

Saya memotong tanggapan darinya, hanya menyisakan permintaan. Inilah yang dikirim, byte demi byte: tcpflow-req.txt

Saya memutar ulang permintaan HTTP yang diambil ini terhadap asciinema. org: 80 dengan nc :

bash-4.4$ (cat tcpflow-req.txt; cat) | nc asciinema.org 80
HTTP/1.1 201 Created
Server: nginx
Date: Mon, 12 Jun 2017 13:30:03 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 48
Connection: close
Status: 201 Created
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Location: http://asciinema.org/a/4lgbbik7li4ywzqrfak0e7eku
ETag: "9beb7ac6bb5981f06fdc71df3947d8b0"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 2a8a8c75-ed06-4741-9adb-e5d276032ded
X-Runtime: 0.360858
Vary: Accept-Encoding
Strict-Transport-Security: max-age=15768000

http://asciinema.org/a/4lgbbik7li4ywzqrfak0e7eku

Semuanya bagus.

Sekarang, saya telah mengirimkan SSL ke asciinema. org: 443 :

(cat tcpflow-req.txt; cat) | openssl s_client -connect asciinema.org:443

Inilah hasilnya:

CONNECTED(00000003)
depth=1 /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/CN=asciinema.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFFDCCA/ygAwIBAgISBDhrp0YwV5NtleFOG+Zj61lQMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzA2MDcwOTEyMDBaFw0x
NzA5MDUwOTEyMDBaMBgxFjAUBgNVBAMTDWFzY2lpbmVtYS5vcmcwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+/g237mVels4G9blsZlaeeiURbSp22eGO
T5OZ5As9NyuxSvRVEJrs4xk/RBEkCVgeZspSOmkRLwXG+FSMtjhbqIUt73AUKMdm
4DG+OwkVxjZatskL0wUWRcU7DmyW/Ls/OFJpPPcZ+pqu/v/ek99EiVNoAHJzXMXJ
ZsWy5KLE3fhkrlyMvdIkOkCK5zHOT95t0i8OmdaPIekPBa57VhvnDlUJsYyCF9GN
mP8Qg6OygexyULJGqBwiZ0BN2J6cYwChUlSvqFnkL4OzfixZ+mItuhl1b1vx/N5K
XMtPiM+nc/S+/liIWgtt7HIy9NmrOtSKbPTh3Bv/rfNdaiYx5CUHAgMBAAGjggIk
MIICIDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFNAMhQNNwl+/bJjml9hrrHYzBxbf
MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMw
YTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9y
ZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9y
Zy8wLwYDVR0RBCgwJoINYXNjaWluZW1hLm9yZ4IVc3RhZ2luZy5hc2NpaW5lbWEu
b3JnMIH+BgNVHSAEgfYwgfMwCAYGZ4EMAQIBMIHmBgsrBgEEAYLfEwEBATCB1jAm
BggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwgasGCCsGAQUF
BwICMIGeDIGbVGhpcyBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBv
biBieSBSZWx5aW5nIFBhcnRpZXMgYW5kIG9ubHkgaW4gYWNjb3JkYW5jZSB3aXRo
IHRoZSBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0cHM6Ly9sZXRzZW5j
cnlwdC5vcmcvcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBABxmJxdQQCcy
FpCkiDrB+vonBUCLYSJtrFkmRdmj9W8/ADpC6M/EhYFOCgrO2cmhYfy1SxDAP5Hd
KIhd3p1F931MMXVcxYt2n6FiDJHN531qp6eBzjZsVIgHXS27PAV466IIMTydNQSe
reyDc9fi+q+ji1Gz89nI8lHIOlRt3dzVGT2J3oQidsm4ZuPNJFj4y8MUrbUAOOH6
YY4n395OKV7vWzl7VPKiCWx+zsv4bzr6IGUPlwqCN2e6cppPWE47ugnYsarINCHO
ie5lU4E2N0k2qVWe/+uYbwSUQ0nrEx8R078m6+6EjDkR4VLboLjuV5tGBgHsJLQB
CmLH6CmNCRE=
-----END CERTIFICATE-----
subject=/CN=asciinema.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3436 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES128-SHA
    Session-ID: AC26CBF8D3719B1DE709A9A8AEAB43D20B14C62085A74604338C512CEA4472C5
    Session-ID-ctx:
    Master-Key: 0C59B1A2B6802D35FAD26DEE139043A853F3E62787E9AA743A8CAFDA95744DB73AB42B511F37EA7D6BB398A352938551
    Key-Arg   : None
    Start Time: 1497273777
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
HTTP/1.0 400 Bad request
Cache-Control: no-cache
Connection: close
Content-Type: text/html

<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.
</body></html>

/ cc @ johnl

@sickill Bisakah Anda memeriksa permintaan yang sama dengan https://ascii.kaos.re?

@andyone baru saja memeriksa. Apakah ini (cat tcpflow-req.txt; cat) | openssl s_client -connect ascii.kaos.re:443 - berhasil diunggah.

Saya telah melakukan lebih banyak penggalian di sini. curl di centos7 menggunakan nss tetapi wget menggunakan openssl. Saya berhasil mengirim permintaan dengan curl atau wget. Saya bahkan dapat mengirim menggunakan alat httpie python (di bawah python 3).

tetapi gagal mengirimnya ke openssl s_client melalui stdin

tetapi berhasil mengirimnya ke openssl s_client dengan menempelkan permintaan ke dalamnya, daripada menggunakan stdin!

Saya sekarang cukup yakin ini karena ada sesuatu yang mengirim permintaan dengan akhiran baris LF daripada akhir baris CRLF yang diperlukan, tapi saya tidak yakin apa. Saya pikir "openssl s_client" adalah alat pengujian yang buruk dan membuatnya sulit untuk memastikan apa yang sedang terjadi.

Tapi saya belum mereproduksi ini dengan klien http yang tepat, apakah menggunakan nss atau openssl (curl di ubuntu menggunakan openssl dan berfungsi dengan baik juga, jadi konfirmasi ganda itu). Ada lagi yang mengaturnya?

Saya baru saja melakukan beberapa pengujian sendiri dan dapat mengonfirmasi bahwa masalah ini tetap ada dengan panjang konten 4520, namun tidak dengan permintaan yang sama yang dihilangkan oleh 1000 karakter ( Content-Length disesuaikan dengan perubahan yang dibuat).

CRLF hadir di semua pengujian saya dan xxd mengonfirmasi bahwa mereka dikirim melalui pipa.
Saya juga dapat menguji dengan OpenBSD nc (yang mendukung TLS).

Dari dokumentasi :

tune.bufsize
Setel ukuran buffer ke ukuran ini (dalam byte). Nilai yang lebih rendah memungkinkan lebih banyak
sesi untuk berdampingan dalam jumlah RAM yang sama, dan nilai yang lebih tinggi memungkinkan beberapa
aplikasi dengan cookie yang sangat besar untuk bekerja. Nilai defaultnya adalah 16384 dan
dapat diubah pada waktu pembuatan. Sangat disarankan untuk tidak mengubah ini
dari nilai default, karena nilai yang sangat rendah akan merusak beberapa layanan seperti
statistik, dan nilai yang lebih besar dari ukuran default akan meningkatkan penggunaan memori,
kemungkinan menyebabkan sistem kehabisan memori. Setidaknya maxconn global
parameter harus dikurangi dengan faktor yang sama seperti yang ini dinaikkan.
Jika permintaan HTTP lebih besar dari (tune.bufsize - tune.maxrewrite), haproxy akan
mengembalikan kesalahan HTTP 400 (Permintaan Buruk). Demikian pula jika respons HTTP lebih besar
dari ukuran ini, haproxy akan mengembalikan HTTP 502 (Gerbang Buruk).

Berbeda dengan nginx yang tidak menyimpan seluruh permintaan dalam memori tetapi meneruskannya dengan cepat (AFAIK) atau paling tidak, melakukan buffer ke dalam file sementara.

Ada no option http-buffer-request Option , yang, jika saya mendapat hak itu menonaktifkan persis perilaku itu (ditulis untuk option http-buffer-request , tanpa no ):

Terkadang diinginkan untuk menunggu isi permintaan HTTP sebelumnya
mengambil keputusan. Inilah yang dilakukan oleh "balance url_param" untuk
contoh. Kasus penggunaan pertama adalah untuk menyangga permintaan dari klien yang lambat sebelumnya
menghubungkan ke server. Kasus penggunaan lain terdiri dari pengambilan rute
keputusan berdasarkan isi tubuh permintaan. Opsi ini ditempatkan di file
frontend atau backend memaksa pemrosesan HTTP untuk menunggu hingga keseluruhannya
body diterima, atau buffer permintaan sudah penuh, atau potongan pertama adalah
selesai jika encoding terpotong. Ini dapat memiliki efek samping yang tidak diinginkan dengan
beberapa aplikasi menyalahgunakan HTTP dengan mengharapkan transmisi unbufferred di antaranya
bagian depan dan bagian belakang, jadi ini pasti tidak boleh digunakan oleh
default.

Saya baru saja memukul ini juga. Saya terkejut bahwa dengan pengujian Anda pada konten yang sama yang bekerja melalui HTTP tetapi tidak HTTPS, sepertinya ukuran buffer tidak salah, kecuali jika sesuatu antara klien Anda dan proxy menambahkan banyak header tambahan.

Tetapi mungkin ada bug dalam apa pun yang menghentikan koneksi SSL Anda sehingga sedikit merusak header.

Jika demikian, ada opsi yang mengurangi keamanan HAProxy, tetapi mengizinkan lalu lintas HTTP yang kurang sesuai. Lihat https://stackoverflow.com/questions/39286346/extra-space-in-http-headers-gives-400-error-on-haproxy

Meskipun saya tidak menganjurkan pengurangan keamanan sebagai perbaikan terakhir, ini memungkinkan Anda untuk mempertahankan layanan saat Anda melakukan debug.

@peterbrittain saat ini asciinema.org menggunakan penyeimbang beban Brightbox Cloud, jadi saya tidak mengontrol konfigurasi Haproxy mereka. Kami biasa menghentikan SSL di Nginx kami sendiri dan itu berfungsi dengan baik. Sejak saya beralih ke BB LB masalah ini terjadi (untuk beberapa). Apakah Anda mengalaminya di bawah CentOS, atau sistem lain?

Terus terang, saya tidak punya masalah dengan solusi berbasis Nginx sebelumnya. Sertifikat SSL kami telah kedaluwarsa jadi saya pikir saya akan menggunakan Let's Encrypt. Karena sertifikat LE berumur pendek, sertifikat LE paling baik dikelola secara otomatis dan Brightbox LB melakukannya untuk saya. Saya hanya ingin menyelamatkan diri dari pekerjaan dalam menyiapkan LE dan BB LB tampaknya menjadi solusi paling sederhana (karena asciinema.org disponsori oleh Brightbox dan berjalan pada infrastruktur mereka yang hebat). Sekarang saya pikir menyiapkan LE sendiri di Nginx mungkin akan memakan waktu 1/10 dari waktu yang sudah saya habiskan untuk memecahkan masalah ini 😞😞😞

Ah. Saya tidak melihat seluk-beluk siapa yang memiliki bagian mana. Apakah Anda beruntung mendapatkan diags dari BB untuk masalah ini?

Dan sebagai jawaban atas pertanyaan Anda: kotak saya adalah VM CentOS 6.

Saya juga baru saja mengalami masalah permintaan yang buruk, menggunakan asciinema 1.2.0 (versi dari ubuntu 16.04 lts).

Peretasan ikal yang diberikan di atas berfungsi, terima kasih.

Saya baru saja menemukan bahwa file yang sama tidak menghasilkan permintaan yang buruk di kotak Gentoo [1] saya, tetapi tidak di kotak OpenBSD [2] saya.
OpenBSD mengunggahnya dengan baik.
Saya pikir harus ada penyelidikan lebih lanjut tentang perbedaan antara klien ini.
Kotak Gentoo mendukung target Python berikut per ebuild:

PYTHON_TARGETS="python3_4 -python3_5"

Saya saat ini tidak dapat menguji python3.5 dengan mudah, tapi mungkin ini sudah membantu.

Sunting : Saya menambahkan versi OpenSSL, benar-benar lupa tentang itu.

• asciinema 1.4.0.0
  
  
  
  • dijalankan menggunakan python-exec 2.4.5
  
  
  • pada gilirannya menjalankan Python 3.4.6
  
  

• OpenSSL 1.0.2l 25 Mei 2017

• asciinema 1.3.0

  • dieksekusi menggunakan Python 3.6.0
• LibreSSL 2.5.2

Saya baru saja beralih kembali ke konfigurasi sebelumnya (menghentikan SSL di Nginx). Beri tahu saya jika berhasil untuk Anda sekarang @andyone @ThiefMaster @benaryorg @peterbrittain @ThomasWaldmann

@sickill Saya hanya 85% yakin itu adalah file yang sama yang gagal sebelumnya, tetapi jika ya, Anda telah memperbaikinya.

@sickill Bekerja seperti pesona bagi saya sekarang. 👍

Yup, sekarang juga bekerja untuk saya (dengan asciinema upload ). Terima kasih!