11

Nếu khách hàng gửi dữ liệu trong loại phương tiện không được hỗ trợ đến máy chủ HTTP, máy chủ sẽ trả lời trạng thái "415 unsupported media type". Nhưng làm thế nào để nói cho khách hàng biết loại phương tiện nào được hỗ trợ? Có một tiêu chuẩn hoặc ít nhất là một cách được đề nghị để làm như vậy? Hay nó chỉ được viết cho cơ thể phản hồi dưới dạng văn bản?Chỉ định loại phương tiện được hỗ trợ khi gửi "415 loại phương tiện không được hỗ trợ"

+1

Bạn mong đợi một tiêu đề Chấp nhận chấp nhận nhưng Chấp nhận chỉ có thể được sử dụng cho các yêu cầu. –

Trả lời

7

Không có đặc điểm kỹ thuật nào cả cho những việc cần làm trong trường hợp này, vì vậy hãy mong đợi triển khai ở mọi nơi. (Điều gì sẽ là hợp lý nếu đáp ứng của máy chủ bao gồm một cái gì đó giống như tiêu đề Accept: vì nó có khá nhiều ngữ nghĩa đúng, nếu hiện sai hướng.)

+0

'Chấp nhận' tiêu đề từ máy chủ đến máy khách sẽ là những gì tôi đang tìm kiếm. Tôi đang mong chờ HTTP 1.2 ;-) – deamon

0

Tôi tin rằng bạn có thể thực hiện điều này với động từ OPTIONS Http.

Cũng có thể sử dụng mã trạng thái 300 Multiple Choices nếu kịch bản của bạn phù hợp với một trường hợp sử dụng nhất định. Nếu họ gửi yêu cầu có tiêu đề Accept của application/xml và bạn chỉ hỗ trợ text/plain và đại diện đó sống ở một URL riêng biệt thì bạn có thể trả lời bằng 300 và trong tiêu đề Vị trí URL của đại diện đó. Tôi nhận ra điều này có thể không chính xác phù hợp với câu hỏi của bạn, nhưng đó là một lựa chọn khác có thể.

Và từ Spec HTTP:

10.4.7 406 Không được chấp nhận

Tài nguyên xác định bởi yêu cầu là chỉ có khả năng tạo ra các đơn vị phản ứng mà có những đặc điểm nội dung không thể chấp nhận theo tiêu đề chấp nhận gửi trong yêu cầu.

Trừ khi đó là yêu cầu HEAD, câu trả lời NÊN bao gồm thực thể chứa danh sách các đặc tính thực thể và (các) vị trí có sẵn mà người dùng hoặc tác nhân người dùng có thể chọn tùy chọn phù hợp nhất. Định dạng thực thể được chỉ định theo loại phương tiện được đưa ra trong trường tiêu đề Loại nội dung. Tùy thuộc vào định dạng và khả năng của tác nhân người dùng, lựa chọn lựa chọn phù hợp nhất CÓ THỂ được thực hiện tự động. Tuy nhiên, đặc điểm kỹ thuật này không xác định bất kỳ tiêu chuẩn nào cho việc lựa chọn tự động như vậy.

 Note: HTTP/1.1 servers are allowed to return responses which are 
     not acceptable according to the accept headers sent in the 
     request. In some cases, this may even be preferable to sending a 
     406 response. User agents are encouraged to inspect the headers of 
     an incoming response to determine if it is acceptable. 
+0

Đó là công việc, ngoại trừ không có thông số kỹ thuật cho nội dung phản hồi ở đó. Nó có thể nói với bạn, nhưng làm sao bạn biết được? –

+0

Nhưng tiêu đề nào nên được sử dụng để nói loại phương tiện nào được hỗ trợ? Tiêu đề này sau đó có thể được sử dụng trong phản hồi '415' trực tiếp. Thông thường 'OPTIONS' chỉ được sử dụng để tìm ra phương thức nào được hỗ trợ. – deamon

+1

'406' không liên quan, vì nó liên quan đến loại không phù hợp với * phản hồi *. '415' là những gì bạn nhận được khi máy chủ không thể xử lý loại dữ liệu trong phần * request *. (Tôi vừa xử lý vấn đề này trong ngữ cảnh của một webservice RESTful mà tôi đang phát triển, vì vậy tôi * chắc chắn * đó là giải thích đúng.) Vấn đề là máy chủ không thể xử lý thông báo và máy khách là đã gửi nó; lỗi là khả năng duy nhất (và không có cách nào để cung cấp cho một cách thích hợp máy có thể đọc được những gì đã làm việc). –

-3

Trong cuốn sách "Sổ tay nhà phát triển HTTP" trên trang 81 Chris Shiflett giải thích ý nghĩa của 415 và sau đó ông nói: "Loại phương tiện được sử dụng trong nội dung của phản hồi HTTP phải được chỉ ra trong tiêu đề thực thể Kiểu nội dung".

1) Vì vậy, hãy nhập nội dung một câu trả lời có thể? Nó có lẽ là danh sách các loại nội dung được chấp nhận bằng dấu phẩy. Vấn đề rõ ràng với khả năng này là Content-Type là tiêu đề thực thể không phải là tiêu đề phản hồi.

2) Hoặc đây có phải là lỗi đánh máy trong sách không? Anh ấy thực sự muốn nói "yêu cầu HTTP"?

+1

Không, không. "Content-Type" * luôn * xác định loại tải trọng của tin nhắn, cả cho các yêu cầu và phản hồi (ngoại trừ các câu trả lời HEAD ...). –

0

tl; dr; Đã chỉnh sửa lớp proxy được tạo để kế thừa từ Microsoft.Web.Services3.WebServicesClientProtocol **.

Tôi đã xem qua câu hỏi này khi khắc phục sự cố lỗi này, vì vậy tôi nghĩ tôi sẽ giúp người tiếp theo có thể đến đây, mặc dù không chắc chắn câu trả lời có được nêu ra hay không. Tôi đã gặp phải lỗi này khi vào một thời điểm nào đó, tôi phải tiếp quản một giải pháp hiện có đang sử dụng mã hóa WSE và MTOM. Đó là một khách hàng Windows gọi một dịch vụ web.

Đến thời điểm này, khách hàng đang gọi dịch vụ web, nơi nó sẽ ném lỗi đó. Điều gì đó góp phần giải quyết lỗi đó cho tôi là kiểm tra lớp proxy dịch vụ web dường như được tạo theo mặc định để kế thừa từ System.Web.Services.Protocols.SoapHttpClientProtocol. Về cơ bản điều đó có nghĩa là nó không thực sự sử dụng WSE3.

Anyhow Tôi đã chỉnh sửa proxy theo cách thủ công và thay đổi nó thành kế thừa từ Microsoft.Web.Services3.WebServicesClientProtocol.

BTW, để xem lớp proxy được tạo trong VS, hãy nhấp vào tham chiếu web và sau đó nhấp vào nút thanh công cụ 'Hiển thị tất cả tệp'. Các reference.cs là nơi da của niềm vui!

Hy vọng điều đó sẽ hữu ích.

Các vấn đề liên quan