2010-07-30 16 views
16

Tôi đã gặp phải lỗi này trong 3 hoặc 4 tuần qua để đưa ra yêu cầu cho công cụ ứng dụng. Một số yêu cầu - đặc biệt là các yêu cầu HTTP DELETE, có lỗi này được trả lại từ máy chủ google.Máy ứng dụng: 400 - Ứng dụng khách của bạn đã đưa ra yêu cầu không đúng định dạng hoặc bất hợp pháp

Những người khác đã thông báo cùng lỗi - với 3 kết quả tôi có thể xác định vị trí

  1. Nguyên nhân là do các tập tin cookie cũ - xóa cookie của bạn và nó chạy tốt gmail help-
  2. Nó được gây ra bởi một url bị thay đổi - chỉ các trường hợp tôi có thể tìm thấy liên quan đến urlfetch() - dấu cách trong url - App engine Group #1, App Engine Group #2
  3. Không có giải pháp - không thường xuyên, chỉ có IE. App Engine Group #3, App Engine Group #4

Tôi hiện đang nhận được hành vi này mọi lúc, mọi trình duyệt. Tôi hoàn toàn có thể xóa bộ nhớ cache/cookie, v.v. trong Chrome, Firefox, Safari, khởi động lại trình duyệt và vẫn nhận được lỗi này một cách đáng tin cậy trên cùng một yêu cầu, vì vậy tôi không nghĩ rằng cookie của nó có liên quan. Trong mọi trường hợp, tôi có thể phát các yêu cầu GET, POST & PUT không có vấn đề gì với cùng một cookie.

Cho rằng nó xảy ra cách đáng tin cậy về các yêu cầu DELETE cụ thể, URL bị thay đổi có vẻ như có nhiều khả năng nhất, tuy nhiên URL của tôi thực sự là rất đơn giản, và hoạt động tốt trên máy chủ dev

Firebug cho thấy tiêu đề yêu cầu như (I đã munged các phím như chúng chứa xác định dữ liệu, nhưng làm như vậy bằng cách loại bỏ các nhân vật từ trung tâm của khóa - không một trong hai kết thúc để đảm bảo tôi không vô tình loại bỏ bất kỳ đứng đầu hoặc cuối)

Request URL:http://my-app.appspot.com/agprhcjgLEgVLbm93dCItX0RrbV9Ea25vd3RfbmV0X19wccxDA/Task.xml 
    Request Method:DELETE 
    Status Code:400 Bad Request 

    Request Headers 
    Accept:*/* 
    Cache-Control:max-age=0 
    Content-Type:application/x-www-form-urlencoded 
    Origin:http://my-app.appspot.com 
    Referer:http://my-app.appspot.com/ 
    User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4 
    X-Requested-With:XMLHttpRequest 

    Form Data 
    entity_key:agprdC1hcjYLEgVLbm93dCIrX09Ea25vd3RfbmV0X19wMQw 

    Response Headers 
    Content-Length:1350 
    Content-Type:text/html; charset=UTF-8 
    Date:Fri, 30 Jul 2010 15:51:58 GMT 
    Server:GFE/2.0 

Câu trả lời tiêu đề cho thấy rằng yêu cầu không bao giờ được thực hiện cho máy chủ của máy ứng dụng (và nhật ký công cụ ứng dụng của tôi chịu sự cố này ra) - một yêu cầu mà thành công làm cho nó đến máy chủ công cụ ứng dụng trông giống như thế này cho tiêu đề phản ứng -

Cache-Control:no-cache 
Content-Length:4332 
Content-Type:application/xml 
Date:Fri, 30 Jul 2010 11:08:21 GMT 
Expires:Fri, 01 Jan 1990 00:00:00 GMT 
Server:Google Frontend 
X-AppEngine-Estimated-CPM-US-Dollars:$0.004033 
X-AppEngine-Resource-Usage:ms=573 cpu_ms=146 api_cpu_ms=30 

Tôi đang xây dựng các yêu cầu sử dụng phương pháp jquery của $ .ajax() và thiết lập các kiểu như 'DELETE' . Ngoài ra, những điều này đã hoạt động gần đây như tuần trước, mặc dù vấn đề đã bắt đầu xuất hiện liên tục. Ngay bây giờ, không có gì tôi làm có hiệu lực.

Hiện tại tôi cho rằng đây là một số lỗi cấu hình/thay đổi trên máy chủ của Google, từ từ leo qua mạng của họ - điều này giải thích tại sao nó bắt đầu liên tục, tăng đều đặn và giờ luôn xảy ra.

Có ai khác có thể gửi yêu cầu HTTP DELETE tới công cụ ứng dụng của Google không? Nếu bạn có, URL của bạn có chứa các khóa tổ chức của công cụ ứng dụng không? Bạn có thể thấy bất cứ điều gì tinh ranh với tôi?

Bất kỳ con trỏ nào khác sẽ được đánh giá cao. Chúc mừng,

Colin

Câu trả lời đầy đủ từ máy chủ google là -

<html><head> 
<meta http-equiv="content-type" content="text/html;charset=utf-8"> 
<title>400 Bad Request</title> 
<style><!-- 
body {font-family: arial,sans-serif} 
div.nav {margin-top: 1ex} 
div.nav A {font-size: 10pt; font-family: arial,sans-serif} 
span.nav {font-size: 10pt; font-family: arial,sans-serif; font-weight: bold} 
div.nav A,span.big {font-size: 12pt; color: #0000cc} 
div.nav A {font-size: 10pt; color: black} 
A.l:link {color: #6f6f6f} 
A.u:link {color: green} 
//--></style> 
<script><!-- 
var rc=400; 
//--> 
</script> 
</head> 
<body text=#000000 bgcolor=#ffffff> 
<table border=0 cellpadding=2 cellspacing=0 width=100%><tr><td rowspan=3 width=1% nowrap> 
<b><font face=times color=#0039b6 size=10>G</font><font face=times color=#c41200 size=10>o</font><font face=times color=#f3c518 size=10>o</font><font face=times color=#0039b6 size=10>g</font><font face=times color=#30a72f size=10>l</font><font face=times color=#c41200 size=10>e</font>&nbsp;&nbsp;</b> 
<td>&nbsp;</td></tr> 
<tr><td bgcolor="#3366cc"><font face=arial,sans-serif color="#ffffff"><b>Error</b></td></tr> 
<tr><td>&nbsp;</td></tr></table> 
<blockquote> 
<H1>Bad Request</H1> 
Your client has issued a malformed or illegal request. 

<p> 
</blockquote> 
<table width=100% cellpadding=0 cellspacing=0><tr><td bgcolor="#3366cc"><img alt="" width=1 height=4></td></tr></table> 
</body></html> 
+0

Đề xuất đầu tiên của bạn (xóa tất cả dữ liệu, cookie, v.v.) đã hoạt động nhờ –

Trả lời

17

Với một HTTP DELETE, URI đầy đủ nên xác định tài nguyên để bị xóa.Gửi dữ liệu bổ sung trong cơ thể yêu cầu là bất ngờ, and on App Engine, unsupported:

Thật vậy, khi frontend appspot thấy một yêu cầu DELETE trong đó bao gồm một cơ quan , chẳng hạn như ứng dụng của bạn, họ trở về một 501. Nhưng, nếu bạn xóa cơ thể, sau đó nó sẽ phục vụ 200.

Dựa trên thảo luận tiếp theo, có vẻ như họ đã quyết định 400 phù hợp hơn 501. Trong mọi trường hợp, nếu bạn bỏ qua cơ thể và di chuyển khóa tổ chức của bạn vào URI, bạn sẽ ổn thôi.

+0

Hi Drew - cảm ơn vì đã nêu bật điều này - chắc chắn trông giống như nguyên nhân của vấn đề. Nó tấn công tôi như là một hạn chế vô cùng ngây thơ - đặc biệt là vì nó không được bắt buộc bởi spec. Bất kể trường hợp sử dụng của tôi, DELETE là một hoạt động khá phức tạp - ví dụ: chúng tôi đang thực hiện xóa cứng hay xóa mềm - lưu trữ là gì? Chắc chắn nó sẽ được lên đến các ứng dụng phục vụ (và không phải là bối cảnh không biết máy chủ web) để xác định 200 hoặc 400 trong tình huống này. Sẽ làm theo điều này lên trên các vấn đề google mà dường như đã được mở lại dựa trên mối quan tâm tương tự. Cám ơn. – hawkett

+1

Tại sao không chỉ theo quy ước? GET/PUT/DELETE sẽ tìm nạp, tạo/ghi đè hoặc loại bỏ tài nguyên chính xác được xác định bởi URI. Các tham số bổ sung cho cả 3 nên đi trên chuỗi truy vấn. Chỉ PUT nên có một cơ thể, và nó phải là nội dung tài nguyên. Nếu bạn XÓA một URI và trả về 200, thì GET hoặc DELETE tiếp theo sẽ là 404. Đối với mọi thứ khác, có POST, điều đó có nghĩa là "gửi một số nội dung tới URI này và mong đợi điều gì đó xảy ra". Nếu bạn muốn xóa hai tài nguyên cùng một lúc, nó sẽ thích hợp hơn để thực hiện điều đó trong POST hơn là cố gắng đưa logic vào DELETE. –

+0

Một vài điểm - 1) nếu dữ liệu phải được mã hóa trên chuỗi truy vấn, thì cú pháp jQuery của DELETE bị hỏng. 2) POST nên được sử dụng để tạo ra một thực thể cấp dưới cho tài nguyên được chỉ định trong URI - Tôi đang làm không có gì thậm chí gần đó - POST sẽ là một hack lớn. 3) PUT không sử dụng tham số truy vấn theo quy ước, bất kỳ DELETE nào không có nội dung 4) Tôi không thể tìm thấy bất kỳ tuyên bố chính thức nào về cơ thể yêu cầu bất ngờ cho DELETE - tác giả tại liên kết của bạn dường như đã được tô điểm các đặc điểm kỹ thuật. Tất cả những gì đã nói, có vẻ như thông số chuỗi truy vấn là đặt cược tốt nhất của tôi. Chỉ cần không thích nó :) Thx – hawkett

2

Tôi đã thấy điều này xảy ra khi xác thực trang web không giải quyết được nhiều người dùng trình duyệt một cách chính xác hoặc đầy đủ. Trong ChromeOS, bản sửa lỗi là đăng xuất hoàn toàn và truy cập trang web khi chỉ có nhận dạng chính được xác thực. Ví dụ: Gmail và Ingress.

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