คำถามติดแท็ก http-status-codes

รหัสสถานะ HTTP คือชุดของรหัสมาตรฐานที่ส่งคืนในการตอบกลับเว็บ HTTP คำถามเกี่ยวกับสาเหตุที่บริการ (โดยไม่คาดคิด) ส่งคืนรหัสสถานะไม่ควรใช้แท็กนี้

3
Python ขอโพสต์ด้วยข้อมูลพารามิเตอร์
นี่คือคำขอดิบสำหรับการเรียก API: POST http://192.168.3.45:8080/api/v2/event/log?sessionKey=b299d17b896417a7b18f46544d40adb734240cc2&format=json HTTP/1.1 Accept-Encoding: gzip,deflate Content-Type: application/json Content-Length: 86 Host: 192.168.3.45:8080 Connection: Keep-Alive User-Agent: Apache-HttpClient/4.1.1 (java 1.5) {"eventType":"AAS_PORTAL_START","data":{"uid":"hfe3hf45huf33545","aid":"1","vid":"1"}}""" คำขอนี้ส่งคืนการตอบกลับสำเร็จ (2xx) ตอนนี้ฉันกำลังพยายามโพสต์คำขอนี้โดยใช้requests: >>> import requests >>> headers = {'content-type' : 'application/json'} >>> data ={"eventType":"AAS_PORTAL_START","data{"uid":"hfe3hf45huf33545","aid":"1","vid":"1"}} >>> url = "http://192.168.3.45:8080/api/v2/event/log?sessionKey=9ebbd0b25760557393a43064a92bae539d962103&format=xml&platformId=1" >>> requests.post(url,params=data,headers=headers) <Response [400]> ทุกอย่างดูดีสำหรับฉันและฉันไม่แน่ใจว่าสิ่งที่ฉันโพสต์ผิดเพื่อให้ได้การตอบสนอง 400


20
เพราะเหตุใด AJAX จึงส่งคืนรหัสสถานะ HTTP 0
ด้วยเหตุผลบางอย่างในขณะที่ใช้ AJAX (กับฉัน Dashcodeแอพลิเคชันที่พัฒนาแล้ว) 0เบราว์เซอร์เพียงแค่หยุดการอัปโหลดและผลตอบแทนของรหัสสถานะ ทำไมสิ่งนี้ถึงเกิดขึ้น

1
รหัสสถานะ HTTP 301 และ 308 แตกต่างกันอย่างไร
HTTP 301และ308รหัสสถานะต่างกันอย่างไร 301 (ย้ายถาวร): คำขอนี้และในอนาคตทั้งหมดควรถูกส่งไปยัง URI ที่กำหนด 308 (การเปลี่ยนเส้นทางถาวร): คำขอและคำขอในอนาคตทั้งหมดควรทำซ้ำโดยใช้ URI อื่น พวกเขาดูเหมือนจะคล้ายกัน

3
รหัสสถานะ HTTP ที่ถูกต้องคืออะไรเมื่อเปลี่ยนเส้นทางไปยังหน้าเข้าสู่ระบบ?
เมื่อผู้ใช้ไม่ได้เข้าสู่ระบบและพยายามเข้าถึงหน้าที่ต้องเข้าสู่ระบบรหัสสถานะ HTTP ที่ถูกต้องสำหรับการเปลี่ยนเส้นทางไปยังหน้าล็อกอินคืออะไร ฉันขอเพราะไม่มี รหัสตอบกลับ 3xx ที่กำหนดโดย W3C ดูเหมือนว่าจะตรงกับข้อกำหนด: 10.3.1 300 ทางเลือกหลายทาง ทรัพยากรที่ร้องขอจะสอดคล้องกับชุดการเป็นตัวแทนชุดใดชุดหนึ่งแต่ละชุดมีตำแหน่งเฉพาะของตนเองและมีการจัดเตรียมข้อมูลการเจรจาที่ขับเคลื่อนด้วยตัวแทน (ส่วนที่ 12) เพื่อให้ผู้ใช้ (หรือตัวแทนผู้ใช้) สามารถเลือกการแสดงที่ต้องการและเปลี่ยนเส้นทางได้ ร้องขอไปยังสถานที่นั้น เว้นแต่จะเป็นคำขอ HEAD การตอบสนองควรรวมเอนทิตีที่มีรายการลักษณะทรัพยากรและตำแหน่งที่ตั้งซึ่งผู้ใช้หรือตัวแทนผู้ใช้สามารถเลือกสิ่งที่เหมาะสมที่สุดได้ รูปแบบเอนทิตีถูกระบุโดยประเภทสื่อที่กำหนดในฟิลด์ส่วนหัวประเภทเนื้อหา ขึ้นอยู่กับรูปแบบและความสามารถของ ตัวแทนผู้ใช้การเลือกตัวเลือกที่เหมาะสมที่สุดอาจดำเนินการโดยอัตโนมัติ อย่างไรก็ตามข้อกำหนดนี้ไม่ได้กำหนดมาตรฐานใด ๆ สำหรับการเลือกอัตโนมัติดังกล่าว หากเซิร์ฟเวอร์มีทางเลือกในการเป็นตัวแทนที่ต้องการเซิร์ฟเวอร์ควรรวม URI เฉพาะสำหรับการแสดงนั้นในฟิลด์ตำแหน่ง ตัวแทนผู้ใช้อาจใช้ค่าฟิลด์ตำแหน่งสำหรับการเปลี่ยนเส้นทางอัตโนมัติ การตอบสนองนี้สามารถแคชได้เว้นแต่จะระบุไว้เป็นอย่างอื่น 10.3.2 301 ย้ายถาวร ทรัพยากรที่ร้องขอได้รับการกำหนด URI ถาวรใหม่และการอ้างอิงในอนาคตไปยังทรัพยากรนี้ควรใช้หนึ่งใน URI ที่ส่งคืน ไคลเอ็นต์ที่มีความสามารถในการแก้ไขลิงก์ควรเชื่อมโยงการอ้างอิงไปยัง Request-URI ใหม่โดยอัตโนมัติกับการอ้างอิงใหม่ที่เซิร์ฟเวอร์ส่งคืนหากเป็นไปได้ การตอบสนองนี้สามารถแคชได้เว้นแต่จะระบุไว้เป็นอย่างอื่น URI ถาวรใหม่ควรได้รับจากฟิลด์ Location ในการตอบกลับ เว้นแต่วิธีการร้องขอคือ …

7
สร้างคำขอด้วย POST ซึ่งรหัสตอบกลับ 200 หรือ 201 และเนื้อหา
สมมติว่าฉันเขียนบริการ REST ซึ่งมีจุดประสงค์เพื่อเพิ่มรายการข้อมูลใหม่ให้กับระบบ ฉันวางแผนที่จะโพสต์ถึง http://myhost/serviceX/someResources สมมติว่าได้ผลฉันควรใช้รหัสตอบกลับอะไร และฉันจะคืนเนื้อหาอะไร ฉันกำลังดูคำจำกัดความของรหัสตอบกลับ HTTP และดูความเป็นไปได้เหล่านี้: 200: ส่งคืนเอนทิตีที่อธิบายหรือมีผลลัพธ์ของการกระทำ 201: ซึ่งหมายถึงสร้างแล้ว ความหมาย * คำขอได้รับการตอบสนองและส่งผลให้มีการสร้างทรัพยากรใหม่ ทรัพยากรที่สร้างขึ้นใหม่สามารถอ้างอิงได้โดย URI ที่ส่งคืนในเอนทิตีของการตอบกลับโดยมี URI ที่เฉพาะเจาะจงที่สุดสำหรับทรัพยากรที่กำหนดโดยฟิลด์ส่วนหัวตำแหน่ง การตอบกลับควรรวมเอนทิตีที่มีรายการลักษณะทรัพยากรและตำแหน่งที่ตั้งซึ่งผู้ใช้หรือตัวแทนผู้ใช้สามารถเลือกสิ่งที่เหมาะสมที่สุดได้ รูปแบบเอนทิตีถูกระบุโดยประเภทสื่อที่กำหนดในฟิลด์ส่วนหัวประเภทเนื้อหา * * * * อันหลังฟังดูสอดคล้องกับข้อมูลจำเพาะ Http มากขึ้น แต่ฉันไม่ชัดเจนว่าอะไร คำตอบควรรวมถึงเอนทิตีที่มีรายการลักษณะทรัพยากรและตำแหน่งที่ตั้ง วิธี ข้อเสนอแนะ? การตีความ?


5
รหัสสถานะ HTTP ที่เหมาะสมที่สุดสำหรับหน้าข้อผิดพลาด“ ไม่พบรายการ” คืออะไร
ฉันสงสัยว่ารหัสสถานะ HTTP ที่เหมาะสมที่สุดสำหรับหน้า "ไม่มีรายการ" คืออะไร ถ้าไม่มีหน้านั้นฉันจะใช้ 404 อย่างชัดเจนอย่างไรก็ตามหน้าหนึ่งของฉันมีuseridอาร์กิวเมนต์ (เป็นหน้า "แก้ไขผู้ใช้") และในกรณีที่ไม่มีผู้ใช้ที่มี ID ผู้ใช้ที่ระบุอยู่ฉันกำลังแสดง หน้าข้อผิดพลาด แต่ฉันต้องการส่งส่วนหัวสถานะ 4xx ด้วย (เนื่องจาก "200 OK" ไม่พอดีจริงๆ) ฉันเดาว่า 404 น่าจะใช้ได้เพราะมัน "ไม่พบ" ไม่ใช่ "ไม่พบไฟล์" แต่ฉันสงสัยว่ามีรหัสที่ดีกว่าสำหรับกรณีนี้หรือไม่

4
รหัสสถานะ HTTP สำหรับคำขอที่ประสบความสำเร็จบางส่วน
ฉันมีแอปพลิเคชันที่ส่งข้อความถึงผู้ใช้ ในคำขอโพสต์จะมีการถ่ายโอนสตริง XML ซึ่งประกอบด้วยผู้ใช้ทั้งหมดที่ควรได้รับข้อความนั้น หากไม่มีผู้ใช้รายใดในรายชื่อฉันให้รายชื่อผู้ใช้ที่หายไปกลับไปยังไคลเอ็นต์เพื่อการประเมินต่อไป ตอนนี้ฉันกำลังถามตัวเองว่ารหัสสถานะที่เหมาะสมสำหรับแอปพลิเคชันจะเป็นอย่างไรโดยบอกว่าคำขอได้รับการยอมรับ แต่มีบางสิ่งที่ไม่สามารถทำได้ ปัญหานี้จะหลีกเลี่ยงได้หากไม่ได้รับอนุญาตให้รวมผู้ใช้ที่ขาดหายไปในรายการ จากนั้นความพยายามในการส่งจะได้รับข้อผิดพลาด 4xx แต่ไม่มีประเด็นในการสร้าง API ด้วยวิธีนี้ ในทางกลับกันฉันสามารถพิจารณาเงื่อนไขข้อผิดพลาดเป็นเฉพาะแอปพลิเคชันเท่านั้น แต่ส่งแค่ 200 ไม่ถนัด และจะเป็นการดีที่จะให้คำแนะนำแก่ลูกค้าว่าเมื่อใดควรพิจารณาการตอบสนองข้อผิดพลาดอย่างลึกซึ้ง เช่นหลีกเลี่ยงการส่งข้อความถึงผู้ใช้นั้นซ้ำแล้วซ้ำเล่า

7
การตอบสนองรหัสสถานะ HTTP ที่เหมาะสมสำหรับคำขอทั่วไปที่ไม่สำเร็จคืออะไร (ไม่ใช่ข้อผิดพลาด)
ฉันกำลังสร้าง RESTful API ที่จะประมวลผลการโต้ตอบของผู้ใช้จำนวนมากรวมถึงการสั่งซื้อโดยใช้บัตรเครดิตที่จัดเก็บไว้ ในกรณีที่คำสั่งซื้อสำเร็จฉันจะส่งคืน 200 OK และในกรณีที่คำขอสั่งซื้อผิดรูปแบบหรือไม่ถูกต้องฉันจะส่งคืน 400 คำขอที่ไม่ถูกต้อง แต่ฉันควรส่งคืนอะไรหากเกิดปัญหาระหว่างการดำเนินการตามคำสั่งซื้อจริง ลูกค้า POSTS สั่งไปยังเซิร์ฟเวอร์สำหรับทรัพยากรผู้ใช้ หากไม่มีผู้ใช้ 404 Not Found จะถูกส่งกลับ รูปแบบคำสั่งซื้อและข้อมูลได้รับการตรวจสอบแล้ว หากไม่ถูกต้อง 400 คำขอที่ไม่ถูกต้องจะถูกส่งกลับ คำสั่งซื้อได้รับการดำเนินการ หากคำสั่งซื้อสำเร็จจะมีการส่งคืน 201 ที่สร้างขึ้นสำหรับคำสั่งซื้อ หากพบข้อผิดพลาดที่ไม่คาดคิดข้อผิดพลาด 500 เซิร์ฟเวอร์จะถูกส่งกลับ ขั้นตอนสุดท้ายคือปัญหา - ฉันจะคืนอะไรได้บ้างหากคำสั่งซื้อไม่สมบูรณ์ด้วยเหตุผลอื่นใด สถานการณ์ที่เป็นไปได้อาจรวมถึง: สินค้าหมด ถึงขีด จำกัด การสั่งซื้อสูงสุดของผู้ใช้แล้ว การทำธุรกรรมบัตรเครดิตล้มเหลว (เงินไม่เพียงพอ ฯลฯ ) ดูเหมือนว่ามันจะไม่เหมาะสมสำหรับ 400 หรือ 500 หากสิ่งใดที่ฉันเห็นว่าเป็น 400 หากไม่มีรหัสที่ดีกว่าคำขอนั้นไม่ถูกต้องตามกฎทางธุรกิจ ดูเหมือนจะไม่ถูกต้อง …

5
ฉันจะแก้ไขข้อผิดพลาด HTTP 414“ ขอ URI ยาวเกินไป” ได้อย่างไร
ฉันได้พัฒนาเว็บแอป PHP ฉันกำลังให้ทางเลือกแก่ผู้ใช้ในการอัปเดตปัญหาต่างๆในครั้งเดียว ในการดำเนินการดังกล่าวบางครั้งผู้ใช้พบข้อผิดพลาดนี้ มีวิธีใดในการเพิ่มความยาวของ URL ใน apache หรือไม่?

12
รหัสสถานะ HTTP 0 - Error Domain = NSURLErrorDomain?
ฉันกำลังทำโปรเจ็กต์ iOS ในแอปพลิเคชันนี้ฉันกำลังดาวน์โหลดภาพจากเซิร์ฟเวอร์ ปัญหา: ในขณะที่ภาพการดาวน์โหลดฉันได้รับการร้องขอหมดเวลา ตามเอกสารรหัสสถานะ HTTP 408ของการร้องขอหมดเวลา แต่ในแอปพลิเคชันของฉันฉันได้รับรหัสสถานะ HTTP 0พร้อมข้อผิดพลาดต่อไปนี้ Error Domain = NSURLErrorDomain Code = -1001 "การร้องขอหมดเวลา" UserInfo = 0xb9af710 {NSErrorFailingURLStringKey = http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg , NSErrorFailingURLKey = http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg , NSLocal requestizedDescription = The ., NSUnderlyingError = 0x13846870 "คำขอหมดเวลา"} ในระหว่างการค้นหาทางอินเทอร์เน็ตฉันไม่พบข้อมูลเกี่ยวกับ HTTP Status Code 0 ใครช่วยอธิบายเรื่องนี้ให้ฉันฟังหน่อย

2
Android: วิธีรับรหัสสถานะของคำขอ HttpClient
ฉันต้องการดาวน์โหลดไฟล์และต้องการตรวจสอบรหัสสถานะการตอบกลับ (เช่นHTTP /1.1 200 OK) นี่คือโค้ดของฉัน: HttpGet httpRequest = new HttpGet(myUri); HttpEntity httpEntity = null; HttpClient httpclient = new DefaultHttpClient(); HttpResponse response = httpclient.execute(httpRequest); ... ฉันจะรับรหัสสถานะของการตอบกลับได้อย่างไร

4
การส่งคืน 202 "ยอมรับ" ในการตอบสนองต่อ HTTP GET ผิดหรือไม่
ฉันมีทรัพยากรชุดหนึ่งที่มีการสร้างตัวแทนขึ้นมาอย่างเกียจคร้าน การคำนวณเพื่อสร้างการแสดงเหล่านี้อาจใช้เวลาตั้งแต่ไม่กี่มิลลิวินาทีจนถึงสองสามชั่วโมงขึ้นอยู่กับการโหลดของเซิร์ฟเวอร์ทรัพยากรเฉพาะและระยะของดวงจันทร์ คำขอ GET แรกที่ได้รับสำหรับทรัพยากรเริ่มต้นการคำนวณบนเซิร์ฟเวอร์ หากการคำนวณเสร็จสิ้นภายในไม่กี่วินาทีการแทนค่าที่คำนวณจะถูกส่งกลับ มิฉะนั้นรหัสสถานะ 202 "ยอมรับ" จะถูกส่งกลับและลูกค้าจะต้องสำรวจทรัพยากรจนกว่าจะมีการเป็นตัวแทนขั้นสุดท้าย สาเหตุของพฤติกรรมนี้มีดังต่อไปนี้: หากผลลัพธ์พร้อมใช้งานภายในไม่กี่วินาทีจำเป็นต้องดึงข้อมูลโดยเร็วที่สุด มิฉะนั้นจะพร้อมใช้งานเมื่อใดก็ไม่สำคัญ เนื่องจากหน่วยความจำที่ จำกัด และจำนวนคำขอที่มากขึ้นทั้ง NIO หรือการสำรวจความคิดเห็นแบบยาวจึงไม่มีทางเลือก ( กล่าวคือฉันไม่สามารถเปิดการเชื่อมต่อได้เกือบเพียงพอและฉันไม่สามารถใส่คำขอทั้งหมดลงในหน่วยความจำได้เลยแม้แต่ครั้งเดียว "ไม่กี่วินาที" ผ่านไปแล้วฉันยังคงดำเนินการตามคำขอส่วนเกิน) ในทำนองเดียวกันข้อ จำกัด ของไคลเอ็นต์คือไม่สามารถจัดการกับการโทรกลับที่สมบูรณ์แทนได้ สุดท้ายโปรดทราบว่าฉันไม่สนใจที่จะสร้างทรัพยากร "โรงงาน" ที่โพสต์หนึ่งรายการเนื่องจากการปัดเศษพิเศษหมายความว่าเราล้มเหลวข้อ จำกัด แบบเรียลไทม์แบบเป็นรายชิ้นมากกว่าที่ต้องการ (ยิ่งไปกว่านั้นมันซับซ้อนเป็นพิเศษนอกจากนี้ยังเป็นทรัพยากรที่จะ ประโยชน์จากการแคช) ฉันคิดว่ามีข้อโต้แย้งเกี่ยวกับการส่งคืนรหัสสถานะ 202 "ที่ยอมรับ" เพื่อตอบสนองต่อคำขอ GET โดยที่ฉันไม่เคยเห็นในทางปฏิบัติและการใช้งานที่ง่ายที่สุดคือการตอบสนองต่อวิธีการที่ไม่ปลอดภัย แต่ฉันไม่เคย พบสิ่งที่ทำให้ท้อใจเป็นพิเศษ ยิ่งไปกว่านั้นฉันไม่ได้รักษาทั้งความปลอดภัยและความเป็นส่วนตัวใช่หรือไม่? แล้วคนคิดอย่างไรเกี่ยวกับแนวทางนี้? แก้ไข : ฉันควรพูดถึงสิ่งนี้สำหรับเว็บ API ที่เรียกว่าธุรกิจไม่ใช่สำหรับเบราว์เซอร์

8
สคริปต์เพื่อรับรหัสสถานะ HTTP ของรายการ URL?
ฉันมีรายการ URL ที่ต้องตรวจสอบเพื่อดูว่ายังใช้งานได้หรือไม่ ฉันต้องการเขียนสคริปต์ทุบตีที่ทำเพื่อฉัน ฉันต้องการรหัสสถานะ HTTP ที่ส่งคืนเท่านั้นเช่น 200, 404, 500 เป็นต้น ไม่มีอะไรมาก แก้ไขโปรดทราบว่ามีปัญหาหากหน้าระบุว่า "ไม่พบ 404" แต่ส่งกลับข้อความ 200 OK เป็นเว็บเซิร์ฟเวอร์ที่กำหนดค่าไม่ถูกต้อง แต่คุณอาจต้องพิจารณากรณีนี้ สำหรับข้อมูลเพิ่มเติมโปรดดูที่ตรวจสอบว่า URL ไปยังหน้าที่มีข้อความ "404" หรือไม่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.