Cách khắc phục sự cố kết nối khi curl nhận được * phản hồi trống *

27

Tôi muốn biết cách tiến hành khắc phục sự cố tại sao yêu cầu cuộn tròn với máy chủ web không hoạt động. Tôi không tìm kiếm sự giúp đỡ phụ thuộc vào môi trường của mình, tôi chỉ muốn biết cách thu thập thông tin về chính xác phần nào của giao tiếp bị lỗi, số cổng, v.v.

chad-integration:~ # curl -v 111.222.159.30
* About to connect() to 111.222.159.30 port 80 (#0)
*   Trying 111.222.159.30... connected
* Connected to 111.222.159.30 (111.222.159.30) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0     OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: 111.222.159.30
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host 111.222.159.30 left intact
curl: (52) Empty reply from server
* Closing connection #0

Vì vậy, tôi hiểu rằng một phản hồi trống có nghĩa là curl không nhận được bất kỳ phản hồi nào từ máy chủ. Không có vấn đề, đó chính xác là những gì tôi đang cố gắng tìm ra.

Nhưng những thông tin cụ thể hơn tôi có thể rút ra từ cURL ở đây?

Nó đã có thể "kết nối" thành công, vì vậy không liên quan đến một số giao tiếp hai chiều? Nếu vậy, tại sao phản ứng không đến cũng được? Lưu ý, tôi đã xác minh dịch vụ của mình đang hoạt động và trả lời phản hồi.

Lưu ý, tôi hơi xanh ở cấp độ mạng này, vì vậy hãy thoải mái cung cấp một số tài liệu định hướng chung.

tcp curl

— chad
nguồn

1

Tôi đã nhận được cùng một lỗi, nhưng trong trường hợp của tôi, đó là phần mềm VPN đã chặn và chặn lưu lượng mạng nhất định. Xem tại đây để biết thêm: stackoverflow.com/a/24189367/703200

— Chris Bartley

16

Bạn có thể sẽ cần khắc phục sự cố này từ phía máy chủ chứ không phải phía máy khách. Tôi tin rằng bạn đang nhầm lẫn giữa một 'phản hồi trống rỗng' với 'không có phản hồi'. Họ không có nghĩa là điều tương tự. Có khả năng bạn đang nhận được một câu trả lời không chứa bất kỳ dữ liệu nào.

Bạn có thể kiểm tra điều này bằng cách sử dụng telnet thay vì sử dụng curl:

telnet 111.222.159.30 80

Sau khi kết nối, dán các mục sau (lấy từ đầu ra curl của bạn):

GET / HTTP/1.1
User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0     OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
Host: 111.222.159.30
Accept: */*

Bạn sẽ thấy phản hồi chính xác như curl thấy nó.

Một lý do có thể khiến bạn nhận được câu trả lời trống là bạn đang cố truy cập một trang web là máy chủ ảo dựa trên tên. Nếu đó là trường hợp, tùy thuộc vào cấu hình máy chủ (trang web bạn đang cố gắng truy cập được cấu hình làm mặc định), bạn không thể truy cập trang web theo địa chỉ IP mà không cần một chút công việc.

Bạn có thể kiểm tra điều đó ở phía máy khách bằng cách thay đổi dòng 'Máy chủ' ở trên; thay thế www.example.com bằng trang web bạn đang cố truy cập:

GET / HTTP/1.1
User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0     OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
Host: www.example.com
Accept: */*

— yoonix
nguồn

Tôi có thể lấy lại trang thành công từ một khách hàng khác. Nó đặc trưng cho các mạng nhất định mà khách hàng có thể đang bật, tôi nghĩ vậy.

— chad

Và, đối với phản hồi trống = không có phản hồi, tôi đã nhận được điều đó từ stackoverflow.com/questions/5929971/ , nhưng tôi sẵn sàng xem xét ý kiến thứ hai;)

— chad

1

Bạn vẫn cần khắc phục sự cố từ phía máy chủ. Nếu máy chủ không gửi dữ liệu, khách hàng sẽ không biết tại sao. Nó chỉ biết rằng nó đã không nhận được nó. Đối với trống rỗng so với không, tôi đã tìm thấy một máy chủ cuộn tròn phàn nàn về phản hồi 'trống rỗng' và tôi chắc chắn đã nhận được phản hồi. * Empty reply from servertừ curl, kết nối trực tiếp cho thấy tất cả các tiêu đề http có liên quan với cơ thể bao gồm hoàn toàn . Nếu nó hoạt động với cuộn tròn ở nơi khác và không phải trên một mạng cụ thể, tôi sẽ xem xét sự khác biệt trên mạng đó. Một proxy hành xử kém có lẽ?

— yoonix

7

Curl là tốt, nhưng không cung cấp nhiều thông tin phản hồi khi mọi thứ đi sai. (Như bạn có thể nói) wget có thể cung cấp cho bạn thêm thông tin, nhưng như yoonix đề cập, phía Máy chủ (tức là nhật ký lỗi máy chủ web) là nơi để xem xét.

wget -S -O /dev/null http://www.example.com

Bạn cũng có thể đặt tên máy chủ với

wget -s -O /dev/null --header="Host: foo.bar" http://www.example.com

— Địa lý
nguồn

2

Hãy thử điều này -> Thay vì đi qua cURL, hãy thử ping trang web bạn đang cố truy cập bằng Telnet. Phản hồi mà nỗ lực kết nối của bạn trả về sẽ chính xác là những gì cURL nhìn thấy khi nó cố gắng kết nối (nhưng nó vô tình che giấu bạn). Bây giờ, tùy thuộc vào những gì bạn thấy ở đây, bạn có thể rút ra một trong nhiều kết luận:

Bạn đang cố gắng kết nối với một trang web là máy chủ ảo dựa trên tên, có nghĩa là không thể truy cập thông qua địa chỉ IP. Đã xảy ra lỗi với tên máy chủ - bạn có thể đã nhập sai thứ gì đó. Lưu ý rằng sử dụng GET thay vì POST cho các tham số sẽ cho bạn câu trả lời cụ thể hơn.

Vấn đề cũng có thể được gắn với tiêu đề 100 tiếp tục. Hãy thử chạy curl_getinfo ($ ch, CURLINEFO_HTTP_CODE) và kiểm tra kết quả.

— Felix
nguồn

1

Lưu ý (vì tôi thấy bạn đã đăng cùng một câu trả lời này trong một câu hỏi cURL khác): những câu hỏi này là về cURL, nhị phân CLI và không phải là triển khai trình bao bọc PHP mà bạn đang tham khảo. Nói cách khác, không có thứ gọi là getinfocờ hoặc tính năng nào cho CLI cURL. @see curl.haxx.se

— ken

0

Trong một số trường hợp dưới WSL của Windows. Chạy curl bên trong bash sẽ tạo ra lỗi tương tự và đó là vì Kasperksy đang chặn nó kết nối với HTTP / s.

Lỗi này đã được báo cáo ở đây .

Một giải pháp nhanh chóng là vô hiệu hóa bảo vệ của Kaspersky trên cổng mà bạn đang cố truy cập trên máy chủ (tcp 80 để lấy bản đồ).

Điều này được thực hiện bằng cách truy cập Kaspersky - Cài đặt - Cài đặt mạng - kiểm tra "Chỉ giám sát các cổng đã chọn" - Chọn cổng - nhân đôi clikc trên cổng (80) và chọn không hoạt động

— AK_
nguồn