Asciinema: CentOS (पायथन 3.4) के तहत 4kb रिकॉर्डिंग के अपलोड के लिए बुरा अनुरोध

मेरे लिए भी होता है। ZSH का उपयोग कर रहा है लेकिन OMZ का नहीं।

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

tmpw6byrbv8-asciinema.json

मैंने पाया कि अगर मैं HT urps से HTTP url को बदल कर HTTP सब ठीक करता है।

मैंने कल लोड बैलेंसर कॉन्फ़िगरेशन बदल दिया है ताकि यह संबंधित हो सके।

मैं इसे Centos 7 Vagrant VM में पुन: पेश करने में सक्षम था। मुझे लगता है कि इसका ब्राइटबॉक्स लोड बैलेंसर (एसएसएल समाप्ति के साथ, स्वचालित लेट्स एनक्रिप्ट प्रमाण पत्र) के साथ कुछ करना है जो हम कल से उपयोग करते हैं।

@andyone @ThiefMaster अब आप कोशिश कर सकते हैं? मैंने इसे हल किया हो सकता है।

अभी भी 400 मिल रहा है

मुझे लगता है कि यह ओपनएसएसएल संबंधित मुद्दा है। कर्ल के साथ डेटा भेजना ठीक है क्योंकि कर्ल SSL / TLS के साथ काम करने के लिए NSS (नेटवर्क सुरक्षा सेवाएँ) का उपयोग करता है।

ब्राइटबॉक्स लोड बैलेंसर के साथ

यह nginx आधारित समाधान है?

@ मुझे लगता है कि Brightbox लोड बैलेंसर Haproxy का उपयोग करता है।

मैं लगातार इसे पुन: पेश कर सकता हूं। मैंने Vagrantfile और निर्देश बनाए: https://github.com/sickill/bb-lb-400

@ समस्या आपके रिकॉर्डिंग में यह विशिष्ट रेखा नहीं है, लेकिन अपलोड की गई जोंस फ़ाइल का समग्र आकार।

मैं एक प्रॉक्सी बनाया https://ascii.kaos.io के आधार पर webkaos (यह BoringSSL के साथ बेहतर nginx है) के साथ इस config । इस प्रॉक्सी पर मेरी और @ThiefMaster रिकॉर्डिंग सफलतापूर्वक अपलोड की

यहाँ मैं अब तक क्या जानता हूँ:

HTTP अनुरोध ब्राइटबॉक्स लोड बैलेंसर के माध्यम से ठीक चलते हैं, लेकिन HTTPS वाले 400 खराब अनुरोध देते हैं
अनुरोध के लिए जहां अनुरोध निकाय 4KB से बड़ा है।

दिलचस्प बात यह है कि हम CentOS के तहत HTTPS के लिए 400 प्राप्त कर रहे हैं। MacOS के तहत HTTPS ठीक काम करता है। (HTTP हर जगह ठीक काम करता है)।

मैंने गहराई से देखा, यह जानने की कोशिश की कि अंतर कहां है। मैंने ccOS और macOS (HTTP दोनों पर अनुरोधों को देखने के लिए tcpdump का उपयोग किया, यह मानकर कि अनुरोध स्वयं HTTPS के समान स्वरूपित है)।

केवल अंतर macOS पर शरीर से पहले 2 खाली लाइनें प्रतीत होता है, CentOS पर 1 खाली लाइन (शायद इन OSes पर पायथन 3 के साथ आने वाले urllib के थोड़े अलग संस्करण के कारण):

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>

मैक ओ एस:

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>

यह देखने के लिए कि यह किस तरह से उन चीजों को प्रभावित करता है जिन्हें मैंने 4096 (डिफ़ॉल्ट) से 8192 (अधिकतम) पर एलबी पर अस्थायी रूप से "अनुरोध बफर आकार" को बदल दिया और यह अचानक हर जगह (सभी ओएसटी, एचटीटीपीएस), ठीक काम करना शुरू कर दिया!

मुझे विश्वास नहीं है कि यह अंतिम समाधान है क्योंकि 4096 के बफर आकार के साथ यह सच है:

• मैं कोई समस्या नहीं के साथ 3MB शरीर के साथ POST अनुरोध करने में सक्षम हूं
  MacOS पर HTTPS
• इस प्रकार मुझे लगता है कि यह बफर आकार हेडर के लिए है न कि अनुरोध निकाय के लिए (इसकी पुष्टि जॉन ने ब्राइटबॉक्स से की थी)
• मैं बिना किसी समस्या के <4KB बॉडी के साथ POST अनुरोध करने में सक्षम हूं
  CentOS पर HTTPS
• मैं CentOS पर HTTPS पर 4KB बॉडी के साथ POST रिक्वेस्ट नहीं कर पा रहा हूं
• ऊपर बफर के बारे में मेरी धारणा के विपरीत केवल हेडर के लिए आवेदन ...
• अनुरोध शीर्षलेख सभी मामलों में छोटे (~ 330 बाइट्स) हैं

जब मैं शरीर के आकार और प्रोटोकॉल को 8192 तक "अनुरोध बफर आकार" टकराता हूं
कोई बात नहीं और सब ठीक काम करता है। मुझे आश्चर्य है कि क्या टकरा कर
यह 8192 तक मैं केवल समय (कम लोगों को प्रभावित) या यह खरीद रहा हूँ
समस्या को पूरी तरह हल करता है (यदि ऐसा है तो क्यों?)।

मैंने इस बारे में ब्राइटबॉक्स से संपर्क किया, उम्मीद है कि वे बता सकते हैं कि क्या चल रहा है।

ब्राइटबॉक्स साइड पर 8192 बफर आकार को अपडेट करें: इस संख्या के साथ यह मेरे लिए CentOS के तहत काम करता है, लेकिन फिर भी @ThmMaster के लिए काम नहीं करता है।

ऑप्स, सॉरी।

इससे पहले कि मैं ब्राइटबॉक्स LB के माध्यम से ट्रैफ़िक डालूं मैंने Nginx में SSL को समाप्त कर दिया और सब कुछ वर्षों से ठीक काम कर रहा था। यदि यह नगनेक्स पर आधारित

मैं इसे हाप्रोसी के साथ बाद में देख सकता हूं, लेकिन मेरा संस्करण ओपनएसएसएल के बजाय लिब्रेएसएसएल के साथ बनाया गया है।

मेरा वर्तमान सिद्धांत यह है:

हेडर और बॉडी से पहले यह एक नई लाइन, पढ़ने वाले हेडर को खत्म करने के लिए एलबी के लिए पर्याप्त नहीं है (यह 2 नई लाइनों की अपेक्षा करता है), और यह हेडर, काउंटिंग बाइट्स के रूप में नीचे दिए गए सभी डेटा को पढ़ता रहता है, जो अंततः हेडर के लिए अधिकतम आकार से अधिक है। यदि LB में कुछ चर जैसे bytes_read (सॉकेट से पढ़े गए बाइट्स) हैं, तो यह हेडर को पढ़ने के बाद, और फिर बाद में शरीर को पढ़ने के बाद इसके मूल्य की जाँच करता है। यदि आप <4kb फ़ाइल अपलोड करते हैं तो यह हेडर के लिए कभी भी 4kb सीमा को पार नहीं करता है, और यदि आप> 4kb अपलोड करते हैं तो यह इससे अधिक हो जाता है।
(और यह केवल HTTPS के तहत होता है)

कोई बात नहीं अगर ऐसा है, तो बस ज़ोर से सोचें case

अद्यतन स्रोत कोड इसलिए यह अतिरिक्त नई लाइन जोड़ता है, CentOS के तहत जाँच की जाती है और अभी भी विफल रहती है। इसलिए उपरोक्त सिद्धांत गलत है।

यह HTTPS के साथ CentOS के तहत काम करता है:

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

तो हो सकता है कि पायथन द्वारा उपयोग किए गए एसएसएल लिबास कर्ल से अलग हो और समस्या एसएसएल-लैंड में कहीं है?

मुझे भी ऐसा ही लगता है। अजगर ओपनएसएसएल का उपयोग करता है, कर्ल एनएसएस का उपयोग करता है।

@ कैंडी ascii.kaos.io के लिए प्रमाण पत्र नहीं है चलो एनक्रिप्ट करें?

रैपिडएसएसएल SHA256withRSA

आम तौर पर मैं कहूंगा कि सेंटोस लेट्स एनक्रिप्ट (या ऐसा ही कुछ) के लिए रूट सर्टिफिकेट गायब है, लेकिन एसएसएल कनेक्शन बनाया जा रहा है और त्रुटि HTTP प्रोटोकॉल लेवल (400 बैड रिक्वेस्ट) पर है ... Cent

अगर लेट्स एनक्रिप्ट के लिए रूट सर्टिफिकेट गायब है तो यह कर्ल के साथ भी काम नहीं करेगा।

हमारा (ब्राइटबॉक्स) लोड बैलेंसर वास्तव में हैप्रोक्सी का उपयोग करता है। HTTP RFC और haproxy डॉक्स यह बताता है कि हेडर को शरीर से अलग करने के लिए एक CRLF की आवश्यकता होती है:

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

क्या यह संभव है कि आप केवल पूर्ण सीआरएलएफ के बजाय यहां सीआर या एलएफ भेज रहे हैं?

@sickill यह HA-Proxy 1.7.5 पर LibreSSL 2.5.0 के साथ https://ascii-ha.kaos.io। इस प्रॉक्सी पर मेरी और @ThiefMaster रिकॉर्डिंग, और over-4k.json अपनी रिपॉजिटरी से सफलतापूर्वक अपलोड की गई।

@ कैंडी ठीक है। तो, क्या आप 4096 में tune.bufsize (https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-tune.bufsize) बदल सकते हैं?

@ जोनल मैंने CRLF के लिए जाँच की और यहाँ सब ठीक है।

मैंने दोनों CentOS और macOS (HTTP पर, फिर से, HTTP पेलोड संभालने के लिए HTTPS के लिए समान है) पर अनुरोध tcpdumped किया।

डंप-centos.pcap.txt और डंप-mac.pcap.txt में tcpdump कैप्चर ( tcpdump -s 0 dst port 80 -w dump-centos.pcap.txt ) होता है।
डंप-सेंटोस-हेक्स.टैक्स और डंप-मैक-हेक्स.टैक्स में हेक्स स्वरूपित डंप होते हैं ( hexdump -C )।

डंप-सेंटोस-हेक्स.टैक्स
डंप-सेंट
डंप-मैक-हेक्स.टैक्स
डंप-mac.pcap.txt

यह दोनों OSes पर लगता है कि CRLF का इस्तेमाल नई लाइनों के लिए किया गया है, और हेडर और बॉडी के बीच एक खाली लाइन है।

बाएं CentOS पर, दाएं MacOS पर:

@sickill कॉन्फ़िग अपडेट की गई। over-4k.json अपलोड किए गए।

@andyone अपडेट के लिए धन्यवाद। ऐसा लगता है कि यह X-Forwarded-Proto शीर्ष लेख नहीं जोड़ता है (क्योंकि लौटा हुआ रिकॉर्डिंग URL http:// )। क्या आप http-request set-header X-Forwarded-Proto https if { ssl_fc } जोड़ सकते हैं?

यह मेरा विन्यास है:

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

मुझे इस पंक्ति को कहां जोड़ना चाहिए?

@ कैंडी मुझे लगता है कि इसे backend अनुभाग में जाने की आवश्यकता है (हालांकि मैं haproxy विशेषज्ञ नहीं हूं)।

@ लिंडन btw, मैं वास्तव में आप इस this धन्यवाद डिबग की मदद की सराहना करते हैं!

आगे के लिए भी मत भूलना। यह ssl सिफर के साथ सेटअप को बहुत बारीकी से दोहराना चाहिए:

    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

मैंने इसे कॉन्फ़िगर किया है, लेकिन बिना किसी भाग्य के:

    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

क्लाइंट अभी भी http:// साथ लिंक लौटाता है।

मुझे हमेशा उपयोगी सेवाओं को बेहतर बनाने में मदद करने में खुशी होती है improve

@ जोनल यह पूर्ण विन्यास है, सभी आवश्यक विकल्प defaults और global अनुभागों में सेट किए गए हैं:

    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

अगर @andyone का हाइप्रोच कॉन्फिगरेशन अब BB के बहुत करीब है और हम अभी भी इस मुद्दे को दोबारा नहीं ला सकते हैं, तो क्या लेट्स एनक्रिप्ट क्रिएट के साथ प्रयास करने का कोई मतलब है? यह https://ascii-ha.kaos.io और https://asciinema.org के बीच के अंतरों में से एक है

यह https://ascii-ha.kaos.io और https://asciinema.org के बीच के अंतरों में से एक है

नहीं। BB LB को ओपनएसएसएल (मैं लिब्रेएसएसएल का उपयोग करता है) के साथ बनाया जा सकता है।

मैं https://ascii-ha.kaos.io के लिए Let’s Encrypt सर्टिफिकेट जोड़ने की कोशिश करूंगा

हो गया - https://ascii.kaos.re
हा-प्रॉक्सी 1.7.5 (w / लिब्रेएसएसएल 2.5.0) + सर्टिफिकेट को एन्क्रिप्ट करें (
विन्यास:

    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

लगता है सभी ठीक काम कर रहे हैं। over-4k.json सफलतापूर्वक अपलोड किया गया।

इसके लिए मेरे पास और कोई विचार नहीं है। मैं लोड संतुलन और एसएसएल समाप्ति के लिए अपने स्वयं के नगनेक्स उदाहरण पर वापस जाने पर विचार कर रहा हूं

मैं इस समस्या को पुन: उत्पन्न कर सकते हैं, जो एक एकल कर्ल आदेश के लिए इसे नीचे की ओर करने की कोशिश कर रहा हूँ, लेकिन अभी तक इसे प्रबंधित नहीं किया है, क्या कोई मदद कर सकता है?

मैं एक 5k बॉडी पोस्ट कर रहा हूं, जिसमें कर्ल का उपयोग करके एक प्रमाणीकरण उपयोगकर्ता नाम / पासवर्ड है। मैं एक नेटबॉक्स वेब सर्वर बैकएंड के साथ एक ब्राइटबॉक्स लोड बैलेंसर मार रहा हूं, इसलिए मैं कच्चा अनुरोध पाठ देख सकता हूं। यह हमेशा गुजरता है - यह एक खराब अनुरोध प्रतिक्रिया को ट्रिगर नहीं कर सकता है।

यदि इसे लोड बैलेंसर द्वारा अस्वीकार किया जा रहा है, तो मुझे बैकएंड पर ऐप के वास्तविक उदाहरण की आवश्यकता नहीं होनी चाहिए, क्योंकि इसे कभी भी ऐसा नहीं करना चाहिए - इसलिए हमें कर्ल और ऐप के साथ इसे पुन: पेश करने में सक्षम होना चाहिए।

मैंने ubuntu और centos7 पर कर्ल की कोशिश की है, और विशेष रूप से ओपनसेल के साथ (ध्यान दें कि आप कर्नल कमांड को कर्ल करने के लिए निर्दिष्ट कर सकते हैं कि कौन सा sslib लिब का उपयोग करना है। सेंटोस 7 कर्ल बायनेरिज़ को सबसे अधिक विकल्पों के खिलाफ बनाया गया है।

@ जोंल को इस पर

परीक्षण के लिए बैकेंड के रूप में netcat का उपयोग करने के लिए समझ में आता है

asciinema upload over-4k.json बराबर कर्ल कमोबेश यही है:

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

(की जगह uuid4 के परिणाम के साथ python3 -c 'import uuid; print(uuid.uuid4())' )

और यह वास्तव में कर्ल के साथ काम करता है ...

मैंने asciinema upload और उपरोक्त कर्ल के tcpdump की तुलना की और HTTP प्रोटोकॉल स्तर पर ऐसा कुछ भी नहीं है जो मुझे संदेहास्पद लगे। हालाँकि, कुछ tcp फ़्रेम विभिन्न स्थानों में दिखाई देते हैं (शायद प्रत्येक tcp पैकेट में अधिक / कम डेटा भेजा / फिट किया जाता है)।

मैंने HTTP अनुरोध (http://asciinema.org पर) CentOS 7 VM में tcpflow के साथ लिया है:

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

फिर दूसरे शेल में (उसी वीएम में) भाग गया:

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

मैंने इसे केवल प्रतिक्रिया छोड़ कर, इससे प्रतिक्रिया काट दी। यहाँ जो भेजा गया है, बाइट बाय बाइट: tcpflow-req.txt

मैंने asciinema के खिलाफ इस कैप्चर किए गए HTTP अनुरोध को फिर से दोहराया। org: 80 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

सब अच्छा।

अब, मैंने एसएसएल को एससिनेमा पर भेज दिया है। org: 443 :

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

यहाँ परिणाम है:

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 @ जोनल

@sickill क्या आप https://ascii.kaos.re के साथ एक ही अनुरोध की जांच कर सकते हैं

@ कैंडी सिर्फ जाँच की। क्या यह (cat tcpflow-req.txt; cat) | openssl s_client -connect ascii.kaos.re:443 - सफलतापूर्वक अपलोड किया गया।

मैंने यहाँ अधिक खुदाई की है। centos7 पर कर्ल nss का उपयोग करता है, लेकिन wget ओपनसेल का उपयोग करता है। मैं सफलतापूर्वक अनुरोध को कर्ल या विग के साथ भेज सकता हूं। मैं भी अजगर httpie उपकरण (अजगर 3 के तहत) का उपयोग कर भेज सकते हैं।

लेकिन यह स्टड के माध्यम से इसे Opensl s_client में भेजने में विफल रहता है

लेकिन यह स्टड का उपयोग करने के बजाए, इसमें अनुरोध को चिपकाकर ओप्सनल s_client को भेजने में सफल होता है!

मुझे अब पूरा यकीन है कि यह इसलिए है क्योंकि कुछ आवश्यक CRLF लाइन एंडिंग के बजाय LF लाइन एंडिंग के साथ अनुरोध भेज रहा है, लेकिन मुझे यकीन नहीं है कि क्या हुआ। मुझे लगता है कि "Opensl s_client" एक खराब परीक्षण उपकरण है और यह सुनिश्चित करना मुश्किल बना रहा है कि क्या चल रहा है।

लेकिन मैंने अभी तक इसे एक उचित http क्लाइंट के साथ पुन: पेश करने के लिए किया है, चाहे nss या खुलता है (ubuntu पर कर्ल का उपयोग करता है, तो Opensl का उपयोग करता है और ठीक भी काम करता है, इसलिए डबल पुष्टि की गई है)। किसी और को प्रबंधित करें?

मैंने अभी अपने दम पर कुछ परीक्षण किया है और पुष्टि कर सकता हूं कि यह समस्या 4520 की सामग्री-लंबाई के साथ बनी हुई है, न कि 1000 वर्णों द्वारा छोड़े गए समान अनुरोध (किए गए परिवर्तनों के अनुसार Content-Length ) के साथ।

CRLF मेरे सभी परीक्षणों में मौजूद है और xxd पुष्टि करते हैं कि उन्हें पाइप पर भेजा गया है।
मैं OpenBSD के nc (जो TLS का समर्थन करता है) के साथ भी परीक्षण कर सकता था।

प्रलेखन से :

धुन
बफर आकार को इस आकार (बाइट्स में) में सेट करता है। कम मूल्य अधिक अनुमति देते हैं
रैम की समान मात्रा में सह-अस्तित्व के सत्र, और उच्चतर मान कुछ की अनुमति देते हैं
काम करने के लिए बहुत बड़ी कुकीज़ के साथ आवेदन। डिफ़ॉल्ट मान 16384 है और
निर्माण समय पर बदला जा सकता है। इसे नहीं बदलने की पुरजोर सिफारिश की गई है
डिफ़ॉल्ट मान से, क्योंकि बहुत कम मान कुछ सेवाओं को तोड़ देंगे जैसे कि
आंकड़े, और डिफ़ॉल्ट आकार से बड़े मूल्य स्मृति उपयोग में वृद्धि करेंगे,
संभवतः स्मृति से सिस्टम को चलाने का कारण। कम से कम वैश्विक अधिकतम
पैरामीटर को उसी कारक से कम किया जाना चाहिए क्योंकि यह एक बढ़ा है।
अगर HTTP रिक्वेस्ट (ट्यून.ब्यूफ़्रीसेज़ - tune.maxrewrite) से बड़ी है, तो haproxy होगा
HTTP 400 (खराब अनुरोध) त्रुटि लौटाएं। इसी तरह अगर एक HTTP प्रतिसाद बड़ा है
इस आकार की तुलना में, haproxy HTTP 502 (खराब गेटवे) लौटाएगा।

के रूप में nginx के लिए जो पूरे अनुरोध को स्मृति में नहीं रखता है, लेकिन इसे मक्खी (AFAIK) पर या बहुत कम से कम, इसे एक अस्थायी फ़ाइल में बफर करता है।

no option http-buffer-request विकल्प है , जो, अगर मुझे मिला है कि यह अधिकार बिल्कुल उस व्यवहार को अक्षम करता है ( option http-buffer-request , बिना no ):

पहले कभी-कभी HTTP अनुरोध के मुख्य भाग के लिए प्रतीक्षा करना वांछनीय है
निर्णय लेना। इसके लिए "संतुलन url_param" द्वारा किया जा रहा है
उदाहरण। पहले उपयोग का मामला पहले धीमे ग्राहकों से बफर अनुरोध करने का है
सर्वर से कनेक्ट करना। रूटिंग लेने में एक और उपयोग का मामला शामिल है
निर्णय अनुरोध निकाय की सामग्री के आधार पर। यह विकल्प एक में रखा गया है
फ्रंटएंड या बैकएंड HTTP प्रोसेसिंग को या तो पूरे होने तक इंतजार करने के लिए मजबूर करता है
शरीर प्राप्त हुआ है, या अनुरोध बफ़र भरा हुआ है, या पहला हिस्सा है
पूर्ण एन्कोडिंग के मामले में। इसके साथ अवांछित दुष्प्रभाव हो सकते हैं
बीच में असंबद्ध प्रसारण की अपेक्षा करके कुछ अनुप्रयोगों ने HTTP का दुरुपयोग किया है
सीमा और बैकएंड, इसलिए इसका उपयोग निश्चित रूप से नहीं किया जाना चाहिए
चूक।

मैंने भी यही मारा है। यह मुझे प्रभावित करता है कि HTTP पर काम करने वाली एक ही सामग्री के परीक्षण के साथ, लेकिन HTTPS नहीं, यह गलती पर बफर आकार होने की संभावना नहीं है, जब तक कि आपके क्लाइंट और प्रॉक्सी के बीच कुछ अतिरिक्त हेडर नहीं जोड़ रहा है।

लेकिन हो सकता है कि आपके SSL कनेक्शन को समाप्त करने में कोई बग हो, जो हेडर को थोड़ा दूषित करता है।

यदि ऐसा है, तो एक विकल्प है जो HAProxy की सुरक्षा को कम करता है, लेकिन HTTP ट्रैफ़िक के कम अनुपालन की अनुमति देता है। Https://stackoverflow.com/questions/39286346/extra-space-in-http-headers-gives-400-error-on-haproxy देखें

हालांकि मैं सुरक्षा को अंतिम रूप देने के लिए कम करने की वकालत नहीं करता, लेकिन जब आप इसे डीबग कर रहे होते हैं, तो यह आपको सेवा को बनाए रखने की अनुमति दे सकता है।

@peterbrittain इस समय asciinema.org ब्राइटबॉक्स क्लाउड लोड बैलेंसर का उपयोग करता है, इसलिए मैं उनके हाप्रोक्सी कॉन्फिग को नियंत्रित नहीं करता हूं। हम एसएसएल को अपने नगनेक्स में समाप्त करते थे और यह ठीक काम कर रहा था। जब से मैंने BB LB पर स्विच किया है यह समस्या होती है (कुछ के लिए)। क्या आप इसे CentOS, या अन्य प्रणाली के तहत अनुभव कर रहे हैं?

सच कहूँ तो, मुझे पिछले Nginx- आधारित समाधान के साथ कोई समस्या नहीं थी। SSL प्रमाणपत्र हमारे पास समाप्त हो रहा था इसलिए मैंने सोचा कि मैं लेट एनक्रिप्ट के साथ जाऊंगा। चूंकि ले केर्ट्स अल्पकालिक हैं, इसलिए वे स्वचालित रूप से प्रबंधित किए जाते हैं और ब्राइटबॉक्स एलबी मेरे लिए ऐसा करता है। मैं सिर्फ ले-अप स्थापित करने में खुद को काम बचाना चाहता था और बीबी एलबी सबसे सरल समाधान लगता था (क्योंकि asciinema.org ब्राइटबॉक्स द्वारा प्रायोजित है और उनके महान बुनियादी ढांचे पर चलता है)। अब मुझे लगता है कि नगनेक्स में खुद को स्थापित करना शायद उस समय का 1/10 हिस्सा होगा जब मैंने पहले से ही इस मुद्दे की शूटिंग में परेशानी का सामना किया

आह। मैं कौन सा बिट्स के स्वामित्व की सूक्ष्मता हाजिर नहीं था। क्या आपको इस मुद्दे के लिए बी बी से कोई भाग्य प्राप्त हो रहा है?

और आपके प्रश्न के उत्तर में: मेरा बॉक्स एक CentOS 6 VM है।

मैंने भी सिर्फ एस्किनिमा 1.2.0 (ubuntu 16.04 lts से संस्करण) का उपयोग करके खराब अनुरोध मुद्दे का अनुभव किया।

ऊपर दिए गए कर्ल हैक ने काम किया, धन्यवाद।

मुझे अभी पता चला है कि बहुत ही फ़ाइल मेरे Gentoo [1] बॉक्स पर खराब अनुरोध करती है, लेकिन मेरे OpenBSD [2] बॉक्स पर नहीं।
OpenBSD इसे ठीक अपलोड करता है।
मुझे लगता है कि इन ग्राहकों के बीच अंतर की और जांच होनी चाहिए।
जेंटो बॉक्स प्रति पुनर्निर्माण निम्नलिखित पायथन लक्ष्यों का समर्थन करता है:

PYTHON_TARGETS="python3_4 -python3_5"

मैं वर्तमान में हालांकि आसानी से python3.5 का परीक्षण नहीं कर सकता, लेकिन शायद यह पहले से ही मदद करता है।

संपादित करें : मैंने ओपनएसएसएल संस्करण जोड़े, उन लोगों के बारे में पूरी तरह से भूल गया।

• asciinema 1.4.0
  
  
  
  • अजगर-निष्पादित 2.4.5 का उपयोग करके निष्पादित
  
  
  • बदले में पायथन 3.4.6 को क्रियान्वित कर रहा है
  
  

• ओपनएसएसएल 1.0.2l 25 मई 2017

• asciinema 1.3.0

  • पायथन 3.6.0 का उपयोग करके निष्पादित
• लिब्रेएसएसएल 2.5.2

मैंने अभी पिछले कॉन्फ़िगर पर वापस लौटा लिया है (Nginx में SSL को समाप्त कर रहा है)। मुझे पता है कि वह आपके लिए काम करता है अब @andyone @ThiefMaster @benaryorg @peterbrittain @ThomasWaldmann

@sickill मुझे केवल 85% यकीन है कि यह वही फ़ाइल है जो पहले विफल हो गई थी, लेकिन यदि यह है, तो आपने इसे ठीक कर लिया है।

@sickill मेरे लिए अब एक आकर्षण की तरह काम करता है। 👍

हाँ, मेरे लिए भी ( asciinema upload ) काम करता है। धन्यवाद!