Tại sao cURL trả lại "nội dung bổ sung không ổn"?

Question

Tôi đang viết một ứng dụng Python truy vấn các API truyền thông xã hội qua cURL. Hầu hết các máy chủ khác nhau tôi truy vấn (Google+, Reddit, Twitter, Facebook, những người khác) có than phiền cURL:

thứ bổ sung không được tốt transfer.c: 1037: 0 0

Điều không bình thường là khi ứng dụng lần đầu tiên bắt đầu, phản hồi của từng dịch vụ sẽ ném dòng này một hoặc hai lần. Sau một vài phút, dòng sẽ xuất hiện vài lần. Rõ ràng cURL đang xác định một cái gì đó mà nó không thích. Sau khoảng nửa giờ, các máy chủ bắt đầu hết thời gian và dòng này được lặp lại nhiều chục lần, vì vậy nó đang hiển thị một vấn đề thực sự.

Tôi có thể chẩn đoán điều này bằng cách nào? Tôi đã thử sử dụng Wireshark để nắm bắt yêu cầu và tiêu đề phản hồi để tìm kiếm các dị thường có thể khiến cURL phàn nàn, nhưng đối với tất cả sự phức tạp của Wireshark thì dường như không có cách nào để tách biệt và chỉ hiển thị tiêu đề.

Dưới đây là phần có liên quan của mã:

output = cStringIO.StringIO() 
c = pycurl.Curl() 
c.setopt(c.URL, url) 
c.setopt(c.USERAGENT, 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0') 
c.setopt(c.WRITEFUNCTION, output.write) 
c.setopt(c.CONNECTTIMEOUT, 10) 
c.setopt(c.TIMEOUT, 15) 
c.setopt(c.FAILONERROR, True) 
c.setopt(c.NOSIGNAL, 1) 

try: 
    c.perform() 
    toReturn = output.getvalue() 
    output.close() 
    return toReturn 

except pycurl.error, error: 
    errno, errstr = error 
    print 'The following cURL error occurred: ', errstr 

Answer 1

Tôi 99,99% chắc chắn đây không phải là thực sự trong bất kỳ tiêu đề HTTP, nhưng thay vì được in để stderr bởi libcurl. Có thể điều này xảy ra ở giữa bạn đăng nhập các tiêu đề, đó là lý do tại sao bạn đã nhầm lẫn.

Dù sao, một tìm kiếm nhanh cho "additional stuff not fine" curl transfer.c bật lên a recent change in the source nơi mô tả là:

Curl_readwrite: tháo gỡ lỗi đầu ra

Văn bản "công cụ bổ sung không được tốt" text đã được bổ sung cho mục đích debug a trong khi trước đây, nhưng nó không thực sự giúp đỡ bất cứ ai và vì lý do nào đó, một số bản phân phối Linux cung cấp libcurls của họ được xây dựng với thông tin gỡ lỗi vẫn còn hiện tại và do đó (quá nhiều) người dùng đọc là thông tin.

Vì vậy, điều này về cơ bản là vô hại, và lý do duy nhất bạn nhìn thấy nó là bạn có một vóc dáng người libcurl (có thể là từ distro linux của bạn) mà đã có đầy đủ debug logging được kích hoạt (mặc dù tác giả curl nghĩ đó là một ý tưởng tồi). Vì vậy, bạn có ba tùy chọn:

1. Bỏ qua nó.
2. Nâng cấp lên phiên bản sau libcurl.
3. Xây dựng lại libcurl mà không có thông tin gỡ lỗi.

Bạn có thể nhìn vào nguồn libcurl cho transfer.c (như liên kết ở trên) để cố gắng hiểu những gì curl được phàn nàn về, và có thể tìm kiếm chủ đề trên mailing list cho cùng một khoảng thời gian hoặc chỉ email trong danh sách và hỏi.

Tuy nhiên, tôi nghi ngờ rằng thực sự có thể không liên quan đến vấn đề thực sự, vì bạn thấy điều này ngay cả ngay từ đầu.

Có ba điều rõ ràng rằng có thể đi sai ở đây:

1. Một lỗi trong curl, hoặc theo cách mà bạn đang sử dụng nó.
2. Đã xảy ra sự cố với thiết lập mạng của bạn (ví dụ: ISP của bạn cắt bạn vì đã tạo quá nhiều kết nối gửi hoặc sử dụng quá nhiều byte trong 30 phút).
3. Việc bạn đang làm là khiến cho các máy chủ cho rằng bạn là kẻ tấn công spammer/DoS/bất kỳ điều gì và chúng đang chặn bạn.

Điều đầu tiên thực sự dường như ít có khả năng nhất. Nếu bạn muốn loại trừ nó, chỉ cần nắm bắt tất cả các yêu cầu bạn thực hiện, và sau đó viết một kịch bản tầm thường sử dụng một số thư viện khác để phát lại các yêu cầu tương tự, và xem bạn có nhận được cùng một hành vi hay không. Nếu vậy, vấn đề rõ ràng là không thể trong việc thực hiện như thế nào bạn thực hiện yêu cầu của bạn.

Bạn có thể phân biệt giữa các trường hợp 2 và 3 dựa trên thời gian. Nếu tất cả các dịch vụ đều hết thời gian — đặc biệt nếu tất cả đều làm như vậy ngay cả khi bạn bắt đầu đánh chúng vào các thời điểm khác nhau (ví dụ: bạn bắt đầu nhấn Google+ 15 phút sau Facebook, nhưng cả hai đều hết thời gian chờ 30 phút sau khi bạn nhấn Facebook) , chắc chắn trường hợp 2. Nếu không, nó có thể là trường hợp 3.

Nếu bạn loại trừ tất cả ba điều này, bạn có thể bắt đầu tìm những thứ khác có thể sai, nhưng tôi bắt đầu ở đây.

Hoặc, nếu bạn cho chúng tôi biết chính xác hơn về những gì ứng dụng của bạn thực hiện (ví dụ: bạn có cố gắng truy cập máy chủ nhiều lần không? Bạn có cố gắng kết nối thay mặt cho một loạt người dùng khác nhau không? bạn có đang sử dụng khóa chính hoặc khóa ứng dụng của người dùng cuối không? v.v), có thể người khác có nhiều kinh nghiệm hơn với các dịch vụ đó để đoán.

Answer 2

Tôi không đồng ý với điều này - Tôi nhận được thông báo tương tự khi cố gọi một trang web qua địa chỉ VIP bên ngoài BIGIP LTM.

Ví dụ:

tôi gọi là trang web http://11five.10.10.10/index.html (địa chỉ IP là ngẫu nhiên trong trường hợp này). BIG F5 nên được cân bằng tải lưu lượng truy cập đến hai máy chủ web nội bộ (17two.20.0.10 và 17two.20.0.11) thông qua một nhóm liên kết với máy chủ ảo.

Trong trường hợp này, yêu cầu đến từ nguồn bên ngoài (Máy khách nội bộ) đến địa chỉ VIP trên TCP 80 nên xoay vòng giữa hai máy chủ web. Những gì tôi thấy là tất cả các máy chủ nhận được một gói SYN ban đầu và không bao giờ trở lại SYN-ACK.

Nếu tôi ngồi trên thiết bị đầu cuối trong mạng con cục bộ nơi máy chủ thực cư trú, tôi có thể "wget" trang web index.html - có nguồn gốc từ 17two.20.0.11 đến http://17two.20.0.10} /index.html.

Đến từ bên ngoài, tôi nhận được * nội dung bổ sung không chuyển tiền tốt.c: 1037 0 0 tin nhắn.

Bạn có quyền nói rằng nó được xây dựng trong cơ chế gỡ lỗi cho CURL trong các phiên bản cũ hơn của thư viện libcurl nhưng tôi không đồng ý với tuyên bố dưới đây;

A bug in curl, or the way you're using it. 
Something wrong with your network setup (e.g., your ISP cuts you off for making too many outgoing connections or using too many bytes in 30 minutes). 
Something you're doing is making the servers think you're a spammer/DoS attacker/whatever and they're blocking you. 

gì bao giờ gây ra điều này là do một vấn đề mạng trong môi trường, IE .. các máy chủ web có thể không trả lại giao thông trở lại nguồn gốc và do đó sẽ hiển thị hoặc hai lỗi này, có cái gì đó sai trái với tiêu đề yêu cầu và phản hồi từ máy chủ web.

Trong trường hợp này tôi sẽ chọn để nói rằng vấn đề ban đầu có nhiều khả năng là khi tôi thực hiện curl bằng URis khác nhau trên yêu cầu ban đầu từ máy chủ thử nghiệm trong mạng con cục bộ, tôi có thể truy xuất trang index.html khỏe. Điều này ngụ ý rằng máy chủ đang lắng nghe và chấp nhận các kết nối bằng cách sử dụng FQDN và tên ngắn của máy chủ.

Tôi tin rằng lỗi này là có để gợi ý rằng curl nhận được phản hồi mà nó không chắc chắn và do đó tạo ra lỗi ở trên. Nếu không phát triển curl hoặc đọc mã nguồn, tôi không thể bình luận thêm.

Bất kỳ phản hồi bổ sung nào đặt câu hỏi về logic này sẽ được hoan nghênh - tất cả đều cho việc học những điều mới.

Andy

Answer 3

xác nhận

Một lỗi trong curl, hoặc theo cách mà bạn đang sử dụng nó.

thông tin systen: Linux alt 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 + deb7u1 x86_64 GNU/Linux

Tôi đã cập nhật thư viện curl, và tin nhắn liên tục (mà đã bị bắt trên thử nghiệm twitter còn lại api)

• thứ bổ sung không được tốt transfer.c: 1037: 0 0

đã biến mất

tôi mới được cập nhật dữ liệu --version curl

$ curl -V

curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.3 librtmp/2.3 Giao thức: tệp dict ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Tính năng: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP