it-swarm-vi.com

Tại sao "Độ dài nội dung: 0" trong POST yêu cầu?

Đôi khi, một khách hàng gửi các yêu cầu POST với Content-Length: 0 khi gửi biểu mẫu (10 đến hơn 40 trường).

Chúng tôi đã thử nghiệm nó với các trình duyệt khác nhau và từ các vị trí khác nhau nhưng không thể tái tạo lỗi. Khách hàng đang sử dụng Internet Explorer 7 và proxy.

Chúng tôi yêu cầu họ để cho quản trị viên hệ thống của họ nhìn nhận vấn đề từ phía họ. Chạy một số thử nghiệm mà không cần proxy, v.v.

Trong khi đó (nửa năm sau và vẫn không có câu trả lời) Tôi tò mò liệu có ai khác biết về các vấn đề tương tự với yêu cầu Content-Length: 0 không. Có thể từ bên trong một số mạng Windows với một proxy đặc biệt cho các công ty lớn.

Có một vấn đề được biết đến với Internet Explorer 7? Với một hệ thống proxy? Bản thân mạng Windows?

Google chỉ cho thấy một cái gì đó trong bối cảnh xác thực NTLM (và như vậy), nhưng chúng tôi không sử dụng điều này trong ứng dụng web. Có lẽ đó là cách proxy hoạt động trong mạng của khách hàng với thông tin đăng nhập Windows? (Tôi không phải là chuyên gia Windows. Chỉ cần đoán.)

Tôi không có thêm thông tin về cơ sở hạ tầng.

CẬP NHẬT: Trong tháng 12 năm 2010, có thể thông báo cho một quản trị viên về điều này, bao gồm. liên kết từ các câu trả lời ở đây. Liên hệ là do một vấn đề khác gây ra bởi proxy. Không có phản hồi kể từ đó. Và các thông báo lỗi vẫn còn đó. Tôi đang cười để ngăn tôi khóc.

CẬP NHẬT 2: Vấn đề này tồn tại từ giữa năm 2008. Cứ sau vài tháng, khách hàng lại thấy khó chịu và muốn nó được sửa chữa càng sớm càng tốt. Chúng tôi gửi lại cho họ tất cả các e-mail cũ và yêu cầu họ liên hệ với quản trị viên của họ để sửa nó hoặc chạy một số bài kiểm tra thêm. Vào tháng 12 năm 2010, chúng tôi đã có thể gửi một số thông tin cho 1 quản trị viên. Không có phản hồi. Vấn đề không được khắc phục và chúng tôi không biết nếu họ thậm chí đã thử. Và vào tháng 5 năm 2011, khách hàng viết lại và muốn sửa lỗi này. Cùng một người có tất cả các thông tin kể từ năm 2008.

Cảm ơn tất cả các câu trả lời. Bạn đã giúp rất nhiều người, như tôi có thể thấy từ một số bình luận ở đây. Quá tệ là thế giới thực là kỳ cục đối với tôi.

CẬP NHẬT 3: Tháng 5 năm 2012 và tôi đã tự hỏi tại sao chúng tôi không nhận được một yêu cầu khác để khắc phục điều này (xem CẬP NHẬT 2). Nhìn vào giao thức lỗi, chỉ báo cáo lỗi này mỗi lần nó xảy ra (khoảng 15 mỗi ngày). Nó đã dừng lại vào cuối tháng 1 năm 2012. Không ai nói gì. Họ phải đã làm một cái gì đó với mạng của họ. Mọi chuyện bây giơ đêu ổn. Từ mùa hè 2008 đến tháng 1 năm 2012. Thật tệ, tôi không thể nói cho bạn biết họ đã làm gì.

CẬP NHẬT 4: Tháng 9 năm 2015. Trang web phải thu thập một số dữ liệu và gửi đến trang web chính của khách hàng. Có một API với một tài khoản. Bất cứ khi nào có vấn đề họ liên lạc với chúng tôi, ngay cả khi vấn đề rõ ràng ở phía bên kia. Trong một vài tuần, chúng tôi không thể gửi cho họ dữ liệu. Tài khoản không còn khả dụng nữa. Họ đã khởi chạy lại và tôi không thể tìm thấy các trang sử dụng dữ liệu của trang web của chúng tôi nữa. Báo cáo lỗi không được trả lời và không ai phàn nàn. Tôi đoán họ vừa kết thúc dự án này.

CẬP NHẬT 5: Tháng 3 năm 2017. API đã ngừng hoạt động vào mùa hè năm 2015. Khách hàng dường như tiếp tục trả tiền cho trang web và vẫn truy cập vào tháng 2 năm 2017. Tôi đoán họ sử dụng nó làm kho lưu trữ. Họ không tạo hoặc cập nhật bất kỳ dữ liệu nào nữa nên lỗi này có thể sẽ không được xử lý lại sau khi sửa lỗi bí ẩn vào tháng 1 năm 2012. Nhưng đây sẽ là vấn đề của người khác. Tôi đi đây.

50
stesch

Internet Explorer không gửi các trường mẫu nếu chúng được đăng từ một trang được xác thực (NTLM) đến một trang không xác thực (ẩn danh). 

Đây là tính năng cho các tình huống phản hồi challange (các trang web được bảo mật NTLM- hoặc Kerberos) trong đó IE có thể mong đợi rằng yêu cầu POST đầu tiên ngay lập tức dẫn đến phản hồi Yêu cầu xác thực HTTP 401 (bao gồm một thách thức) và chỉ yêu cầu POST thứ hai (bao gồm phản hồi cho cuộc trò chuyện) mới thực sự được chấp nhận. Trong các tình huống này IE không tải lên phần yêu cầu có thể lớn với yêu cầu đầu tiên vì lý do hiệu suất. Cảm ơn EricLaw đã đăng một chút thông tin trong các bình luận.

Hành vi này xảy ra mỗi khi HTTP POST được tạo từ trang NTLM xác thực (tức là Intranet) sang trang không được xác thực (tức là Internet) hoặc nếu trang không được xác thực là một phần của bộ khung, trong đó bộ khung trang được xác thực.

Cách xử lý là sử dụng yêu cầu GET làm phương thức biểu mẫu hoặc để đảm bảo trang không được xác thực được mở trong một tab/cửa sổ mới (mục tiêu yêu thích/liên kết) mà không có bộ khung xác thực một phần. Ngay khi mô hình xác thực cho toàn bộ cửa sổ nhất quán, IE sẽ bắt đầu gửi lại nội dung biểu mẫu.


40
Tomalak

Điều này dễ dàng tái tạo với MS-IE và bộ lọc xác thực NTLM ở phía máy chủ. Tôi có cùng vấn đề với JCIFS (1.2 .), thanh chống 1. và MS-IE 6/7 trên XP-SP2. Cuối cùng nó đã được sửa. Có một số cách giải quyết để làm cho nó lên. 

  1. thay đổi phương thức biểu mẫu từ POST (cài đặt mặc định struts) thành GET. Đối với hầu hết các trang có hình dạng kích thước nhỏ, nó hoạt động tốt. Thật không may, tôi có thể có hơn 50 bản ghi để gửi luồng HTTP trở lại phía máy chủ. IE có giới hạn URL GET 2038 byte (không phải độ dài tham số, nhưng toàn bộ chiều dài URL). Vì vậy, đây là một cách giải quyết nhanh chóng nhưng không áp dụng cho tôi.

  2. gửi GET trước POST thực thi hành động. Điều này được khuyến nghị trong MS-KB. Dự án của tôi có nhiều thủ tục kế thừa và tôi sẽ không chấp nhận rủi ro vào đúng thời điểm. Tôi chưa bao giờ thử điều này bởi vì nó vẫn cần một số xử lý xác thực bổ sung khi lớp GET được nhận bởi lớp bộ lọc dựa trên sự hiểu biết của tôi từ MS-KB và tôi không muốn thay đổi hành vi với các trình duyệt khác, ví dụ: Firefox, Opera.

  3. phát hiện nếu POST được gửi với độ dài nội dung bằng không (bạn có thể lấy nó từ cấu trúc băm thuộc tính tiêu đề với khung của bạn). Nếu vậy, hãy kích hoạt chu trình xác thực NTLM bằng cách nhận mã thử thách từ DC hoặc bộ đệm và mong đợi phản hồi NTLM. Khi nhận được thông báo NTLM type2 và phiên vẫn hợp lệ, bạn không thực sự cần xác thực người dùng mà chỉ chuyển tiếp nó tới hành động dự kiến ​​nếu POST độ dài nội dung không bằng không. BTW, điều này sẽ làm tăng buôn bán mạng. Vì vậy, hãy kiểm tra cài đặt thời gian sử dụng bộ nhớ cache của bạn và SMB phiên cấu hình soTimeOut trước khi áp dụng thay đổi . Hoặc đơn giản hơn, bạn có thể gửi trạng thái trái phép 401 tới MS-IE và trình duyệt sẽ gửi trở lại POST yêu cầu có dữ liệu trả lời.

  4. MS-KB đã cung cấp bản sửa lỗi nóng với KB-923155 (Tôi không thể đăng nhiều hơn một liên kết vì số danh tiếng thấp: {), nhưng có vẻ như nó không hoạt động. Ai đó sẽ gửi một sửa chữa nóng khả thi ở đây? Cảm ơn :) Đây là một liên kết để tham khảo, http://www.websina.com/ormszero/kb/browser-ie.html

14
maxwu

Chúng tôi có một khách hàng trên hệ thống của chúng tôi với cùng một vấn đề. Chúng tôi đã chỉ nó xuống proxy/tường lửa. IAS của Microsoft. Đó là tước thân POST và gửi độ dài nội dung: 0. Tuy nhiên, chúng tôi không thể làm gì nhiều để xử lý các yêu cầu GET vì điều này làm lộ tên người dùng/mật khẩu, v.v. trên chuỗi URL. Có gần 7.000 người dùng trên hệ thống của chúng tôi và chỉ có một người gặp sự cố ... cũng chỉ có một người sử dụng Microsoft IAS, vì vậy nó phải như vậy.

6
Scott

Có một cơ hội tốt là vấn đề là máy chủ proxy ở giữa triển khai HTTP 1.0.

Trong HTTP 1.0, bạn phải sử dụng trường tiêu đề Độ dài nội dung: ( Xem phần 10.4 tại đây )

Độ dài nội dung hợp lệ là bắt buộc trên tất cả các yêu cầu HTTP/1.0 POST. Một Máy chủ HTTP/1.0 phải trả lời bằng 400 tin nhắn (yêu cầu xấu) nếu không thể xác định độ dài của yêu cầu nội dung tin nhắn.

Yêu cầu đi vào proxy là HTTP 1.1 và do đó không cần sử dụng trường tiêu đề Độ dài nội dung. Tiêu đề Độ dài nội dung thường được sử dụng nhưng không phải lúc nào cũng vậy. Xem đoạn trích sau từ HTTP 1.1 RFC S. 14.13

Các ứng dụng NÊN sử dụng lĩnh vực này để cho biết độ dài chuyển của tin nhắn cơ thể, trừ khi đây là bị cấm theo các quy tắc trong phần 4,4 . Bất kỳ Độ dài nội dung nào lớn hơn hoặc bằng 0 là một giá trị hợp lệ.

Mục 4.4 mô tả cách xác định chiều dài của phần thân thông điệp nếu a Độ dài nội dung không được đưa ra.

Vì vậy, máy chủ proxy không thấy tiêu đề Độ dài nội dung mà nó cho là hoàn toàn cần thiết trong HTTP 1.0 nếu có phần thân. Vì vậy, nó giả sử 0 để yêu cầu cuối cùng sẽ đến máy chủ. Hãy nhớ rằng proxy không biết các quy tắc của thông số HTTP 1.1, vì vậy nó không biết cách xử lý tình huống khi không có tiêu đề Độ dài nội dung. 

Bạn có chắc chắn 100% yêu cầu của bạn đang chỉ định tiêu đề Độ dài nội dung không? Nếu nó đang sử dụng một phương tiện khác như được định nghĩa trong phần 4.4 vì nó nghĩ rằng máy chủ là 1.1 (vì nó không biết về proxy 1.0 ở giữa) thì bạn sẽ gặp vấn đề được mô tả. 

Có lẽ bạn có thể sử dụng HTTP GET thay vì bỏ qua vấn đề. 

4
Brian R. Bondy

Đây là một vấn đề đã biết đối với Internet Explorer 6, nhưng không phải là 7 mà tôi biết. Bạn có thể cài đặt bản sửa lỗi này cho bản sửa lỗi IE6 KB831167 .

Bạn có thể đọc thêm về nó ở đây

Một số câu hỏi cho bạn:

  • Bạn có biết loại proxy nào không?
  • Bạn có biết nếu có một cơ thể thực sự được gửi trong yêu cầu?
  • Nó xảy ra nhất quán mọi lúc? Hay chỉ đôi khi?
  • Có bất kỳ dữ liệu nhị phân được gửi trong yêu cầu? Có thể dữ liệu bắt đầu bằng\0 và proxy có lỗi với dữ liệu nhị phân. 
3
Brian R. Bondy

Nếu người dùng đang trải qua proxy ISA sử dụng xác thực NTLM, thì có vẻ như sự cố này đã được cung cấp giải pháp (bản vá cho proxy ISA)

http://support.Microsoft.com/kb/942638
Các yêu cầu POST không có phần thân POST có thể được gửi đến máy chủ Web được xuất bản trong ISA Server 2006

2
GStephens

Bạn có chắc chắn những yêu cầu này đến từ một "khách hàng"?

Tôi đã có vấn đề này với bot trước đây; đôi khi họ thăm dò các trang web cho các biểu mẫu "liên hệ với chúng tôi" bằng cách gửi các yêu cầu POST trống dựa trên URI hành động trong các thẻ FORM mà họ phát hiện trong khi thu thập thông tin.

1
JasonTrue

Sự hiện diện và các giá trị có thể có của tiêu đề ContentLpm trong HTTP được mô tả trong RFC HTTP (Tôi giả sử 1/1):

http://www.w3.org/Prot Protocol/rfc2616/rfc2616-sec14.html # sec14.13

Trong HTTP, nó NÊN được gửi bất cứ khi nào độ dài của tin nhắn có thể được xác định trước khi được chuyển

Xem thêm:

Nếu nhận được tin nhắn với cả a Trường tiêu đề chuyển mã hóa và trường tiêu đề Độ dài nội dung, cái sau PHẢI được bỏ qua.http://www.w3.org/Prot Protocol/rfc2616/rfc2616-sec4.html # sec4.4

Có lẽ thư của bạn đang mang tiêu đề Mã hóa chuyển?

Chỉnh sửa sau: cũng xin lưu ý "NÊN" như được sử dụng trong RFC là rất quan trọng và không tương đương với "PHẢI":

3. NÊN Lời này, hoặc tính từ "KHUYẾN NGHỊ", có nghĩa là có có thể tồn tại những lý do hợp lệ trong các trường hợp cụ thể để bỏ qua a mục cụ thể, nhưng ý nghĩa đầy đủ phải được hiểu và cân nhắc cẩn thận trước khi chọn một khóa học khác nhau. Tham chiếu: http://www.ietf.org/rfc/rfc2119.txt

1
diciu

curl gửi PUT/POST yêu cầu với Content-Length: 0 khi được định cấu hình để sử dụng HTTP proxy. Đó là mẹo để vượt qua bộ đệm cần thiết trong trường hợp yêu cầu PUT/POST trái phép đầu tiên được ủy quyền. Trong trường hợp GET/HEAD yêu cầu curl chỉ cần lặp lại truy vấn. Lược đồ cho PUT/POST giống như:

  1. Gửi yêu cầu PUT/POST đầu tiên với Content-Length được đặt thành 0.

  2. Nhận câu trả lời. Mã trạng thái HTTP là 407 có nghĩa là chúng ta phải sử dụng proxy Ủy quyền. Chuẩn bị các tiêu đề để xác thực proxy cho yêu cầu gửi.

  3. Gửi yêu cầu một lần nữa với các tiêu đề được điền để xác thực proxy và dữ liệu thực tới POST/PUT.

0
user1641854

Chúng tôi đã có một khách hàng sử dụng cùng một trang web ở chế độ ẩn danh và NTLM (trên các cổng khác nhau). Chúng tôi phát hiện ra rằng trong trường hợp của chúng tôi, 401 có liên quan đến ứng dụng Riverbed Steelhead được sử dụng để tối ưu hóa http. Tín hiệu đầu tiên hướng chúng ta theo hướng đó là tiêu đề X-RBT-Optimized-By. Vấn đề là tính năng Gratuitous 401:

Tính năng này có thể được sử dụng với cả yêu cầu và mỗi kết nối xác thực nhưng nó hiệu quả nhất khi được sử dụng với mỗi yêu cầu xác thực. Với xác thực theo yêu cầu, mọi yêu cầu phải là được xác thực với máy chủ trước khi máy chủ phục vụ đối tượng cho khách hàng. Tuy nhiên, hầu hết các trình duyệt không lưu bộ đệm của máy chủ phản hồi yêu cầu xác thực và do đó nó sẽ lãng phí một khứ hồi cho mọi yêu cầu NHẬN. Với Gratuitous 401, phía khách hàng Thiết bị Steelhead sẽ lưu trữ phản hồi của máy chủ và khi máy khách gửi yêu cầu GET mà không có bất kỳ tiêu đề xác thực nào, nó sẽ phản hồi cục bộ với tin nhắn ―401 trái phép và do đó tiết kiệm một chuyến đi khứ hồi. Lưu ý rằng mô-đun HTTP không tham gia vào xác thực thực tế. Những gì mô-đun HTTP làm là thông báo máy khách mà máy chủ yêu cầu xác thực mà không yêu cầu Nó để lãng phí một chuyến đi khứ hồi.

0
wdk

Tôi cũng gặp sự cố khi yêu cầu từ trình duyệt IE 11 của khách hàng có Content-Length: 0 và không bao gồm nội dung POST dự kiến. Khi khách hàng sử dụng Firefox hoặc Chrome, nội dung dự kiến ​​sẽ được đưa vào yêu cầu.

Tôi đã tìm ra nguyên nhân là do khách hàng sử dụng URL HTTP thay vì URL HTTPS (ví dụ: http://..., không phải https://...) và ứng dụng của chúng tôi sử dụng HSTS. Có vẻ như có một lỗi trong IE 11 khi yêu cầu được nâng cấp lên HTTPS do HSTS, nội dung yêu cầu bị mất.

Bắt khách hàng sửa URL thành https://... dẫn đến nội dung được đưa vào yêu cầu POST và giải quyết vấn đề.

Tôi chưa điều tra liệu nó có thực sự là một lỗi trong IE 11 nữa ở giai đoạn này hay không.

0
matthewrwilton

Hotfix của Microsoft cho KB821814 có thể đặt Độ dài nội dung thành 0:

Các hotfix mà bài viết này mô tả thực hiện thay đổi mã trong Wininet.dll thành:

  • Phát hiện điều kiện RESET theo yêu cầu POST.
  • Lưu dữ liệu sẽ được đăng.
  • Thử lại yêu cầu POST với độ dài nội dung được đặt thành 0. Điều này ngăn việc đặt lại xảy ra và cho phép quá trình xác thực hoàn tất.
  • Thử lại yêu cầu POST ban đầu.
0
user151236

Google cũng cho thấy đây là lỗi IE (một số phiên bản, dù sao) sau khi kết nối https chạm vào thời gian chờ cố định và kết nối lại với máy chủ. Giải pháp dường như là định cấu hình máy chủ để không sử dụng thủ tục cho IE trong https.

0
ysth