| HTTP statuskod | Statuskod betydelse |
|---|
| 100 | Kundsidan bör fortsätta att skicka förfrågningar. Det här tillfälliga svaret används för att informera kundsidan att några av dess förfrågningar har mottagits av servern och inte har förnekats. Kundsidan bör fortsätta att skicka resten av förfrågan, eller ignorera svaret om förfrågan har slutförts. Servern måste skicka ett slutligt svar till kundsidan efter att förfrågan har slutförts. |
| 101 | Servern har förstått klientens förfrågan och kommer att informera klientens sida genom att använda Upgrade-header att använda ett annat protokoll för att slutföra förfrågan. Efter att ha skickat den sista tomma raden i svaret kommer servern att byta till de protokoll som definieras i Upgrade-header. Liknande åtgärder bör endast vidtas när övergången till ett nytt protokoll är mer fördelaktig. Till exempel har övergången till en ny HTTP-version fördelar jämfört med en gammal version, eller övergången till en verklig-tid och synkron protokoll för att leverera resurser som utnyttjar sådana funktioner. |
| 102 | Statuskoden utökad av WebDAV (RFC 2518) indikerar att behandlingen kommer att fortsätta. |
| 200. | Förfrågan var framgångsrik, och de önskade svarshuvuden eller datakropparna returneras med svaret. |
| 201 | Förfrågan har uppfyllts, och en ny resurs har skapats baserat på kraven i förfrågan, och dess URI har returnerats med Location-headers. Om den krävda resursen inte kan skapas i tid,'202 Accepterad' bör returneras. |
| 202 | Servern har accepterat förfrågan, men har inte bearbetat den ännu. Precis som den kan avvisas, kan förfrågan antingen eller inte utföras till slut. I fallet med asynkrona operationer finns det ingen mer bekväm metod att göra detta än att skicka denna statuskod. Syftet med att återkomma med 202 statuskod som svar är att tillåta servern att acceptera förfrågningar från andra processer (som en batch-en baserad operation som utförs endast en gång om dagen) utan att behöva hålla klientens sida ansluten till servern tills batchoperationen är klar. Som svar på att acceptera en förfrågan om behandling och återkomma med en 202 statuskod, bör den returnerade entiteten inkludera viss information som indikerar den aktuella processens tillstånd, samt en pekare till processstatusövervakaren eller statusprognosen, så att användaren kan uppskatta om operationen har slutförts. |
| 203 | servern har behandlat begäran framgångsrikt, men den returnerade entitetsrubriken metadata är inte en giltig deterministisk uppsättning på ursprungsservern, utan är en lokal eller tredje-partskopia. Den aktuella informationen kan vara en delmängd eller en övermängd av den ursprungliga versionen. Till exempel kan metadata som innehåller resurser få ursprungsservern att känna till meta super. Användning av denna statuskod är inte nödvändig och är endast lämplig om svaret returnerar 200 OK utan denna statuskod. |
| 204 | servern behandlade begäran framgångsrikt, men behöver inte returnera något fysiskt innehåll och vill returnera uppdaterad metadata. Svaret kan vara i form av en entitetsrubrik, som returnerar ny eller uppdaterad metadata. Om denna rubrikinformation finns, bör den korrespondera med den begärda variabeln. Om klienten är en webbläsare, bör användarens webbläsare behålla sidan som skickade begäran utan några ändringar i dokumentvyn, även om nya eller uppdaterade metadata skulle tillämpas på dokumentet i användarens aktiva webbläsarvy enligt specifikationen. Eftersom den 204 svar förbjuds att inkludera någon meddelandekropp, det slutar alltid med den första tomma raden efter rubriken. |
| 205 | servern behandlade begäran framgångsrikt och returnerade ingenting. Men i motsats till den 204 svar, svaret som returnerar denna statuskod kräver att begäranaren återställer dokumentvyn. Detta svar används huvudsakligen för att återställa formuläret omedelbart efter att användarinput har accepterats, så att användaren enkelt kan börja med en annan input. Som den 204 svar, detta svar är också förbjudet att inkludera något meddelandekropp och slutar med den första tomma raden efter huvudet. |
| 206 | Servern har framgångsrikt bearbetat en del av GET-förfrågan. HTTP-downladdningsverktyg som FlashGet eller Xunlei använder denna typ av svar för att implementera en brytpunktfortsättning eller att bryta upp ett stort dokument i flera nedladdningssegment för samtidig nedladdning. Förfrågan måste innehålla ett Range-huvud för att indikera intervallet av innehåll som klientsidan vill ha, och kan inkludera If-Range som en förfrågningsförutsättning. Svaret måste innehålla följande huvudfält: Content-Range för att indikera intervallet för innehållet som returneras i detta svar; om det är ett multi-segment download med Content-Typ multipart/byteranges, bör varje delmängd innehålla ett Content-Range-fältet för att indikera innehållsintervallet för denna segment. Om svaret innehåller Content-Längd, då dess värde måste matcha det faktiska antalet byte i innehållsintervallet det returnerar. Datum ETag och/eller Innehåll-Plats, om samma förfrågan skulle ha återkommit en 200-svar. Uppdateringsdatum, Cache-Kontroll, och/eller Vary, om dess värde kan vara annorlunda än värdet som motsvarar andra svar till samma variabel innan. Om detta svarförfrågan använder If-Range-stark sockervärdering, då detta svar bör inte inkludera andra entitetshuvuden; om detta svarförfrågan använder If-Range-sockervärdering är svag, då detta svar bör inte inkludera andra entitetshuvuden; detta undviker inkonsekvenser mellan cachat innehåll och uppdaterad entitetshuvudinformation. Annars bör detta svar innehålla alla entitetshuvudfält som bör returneras i en 200-svar. Om ETag eller Last-Modified-huvuden matchar inte exakt, klientsidan cache bör förbjuda kombination av innehållet som returneras i 206 svar med något tidigare cachat innehåll. Varje cache som inte stöder Range och-Range-huvudet tillåts inte att cacha innehållet som returneras av 206 svar. |
| 207 | En statuskod utökad av WebDAV (RFC 2518) represents that the body of the subsequent message will be an XML message, and may contain a series of independent response codes depending on the number of previous sub-) representerar att kroppen för det följande meddelandet kommer att vara ett XML-meddelande och kan innehålla en serie oberoende svarskoder beroende på antalet tidigare under |
| 300 | requests.-The requested resource has a range of feedback options, each with its own specific address and browser--specifikationen anger inte hur denna automatiska valprocess ska genomföras. Om servern själv redan har en föredragen feedbackval, bör URI:en för feedback anges i Location; webbläsare kan använda detta Location-värde som adress för automatisk omdirigering. Dessutom är svaret också cachbart om inte annat anges. 2616 Typ. Webbläsaren kan automatiskt göra det mest lämpliga valet baserat på formatet för svaret och webbläsarens egna förmågor. Naturligtvis, RFC-driven förhandling information. Användaren eller webbläsaren kan välja en föredragen adress för omdirigering. Om detta inte är en HEAD-förfrågan bör svaret inkludera ett element med en lista över resursattribut och adresser från vilka användaren eller webbläsaren kan välja den mest lämpliga omdirigeringsadressen. Formatet för detta element bestäms av formatet definierat av Content |
| 301 | Begärd resurs har permanent flyttats till en ny plats, och alla framtida referenser till denna resurs bör använda en av flera URI:er som returneras av detta svar. Om möjligt bör klienten med länkredigeringsförmåga automatiskt ändra den begärda adressen till den adress som returneras från servern. Om inte annat anges är detta svar också cachbart. Den nya permanenta URI:en bör returneras i Location-fältet i svaret. Om detta inte är en HEAD-förfrågan bör svarselementet innehålla en hyperlinke till den nya URI:en och en kort beskrivning. Om detta inte är en GET eller HEAD-förfrågan är webbläsaren förbjuden att automatiskt omdirigera om inte användaren bekräftar det, eftersom förhållandena för förfrågan kan förändras som ett resultat. Notera: För vissa webbläsare som använder HTTP-specifikationen anger inte specifikationen hur denna automatiska valprocess ska genomföras. Om servern själv redan har en föredragen feedbackval, bör URI:en för feedback anges i Location; webbläsare kan använda denna Location-värde som adress för automatisk omdirigering. Dessutom är svaret också cachbart om inte annat anges./1.0-protokollet, när de skickar en POST-förfrågan och får en 301 svar, kommer den efterföljande omdirigeringsförfrågan att vara GET. |
| 302 | den efterfrågade resursen svarar nu tillfälligt på förfrågan från en annan URI. Eftersom sådana omdirigeringar är tillfälliga, bör klienten fortsätta att skicka framtida förfrågningar till den ursprungliga adressen. Detta svar kan cachas endast om specificerat i Cache-Kontroll eller Uppdateringsdatum. Den nya tillfälliga URI:en bör returneras i svarsfältets Location. Om detta inte är en HEAD-förfrågan, bör svarselementet innehålla en hyperlinke till den nya URI:en och en kort beskrivning. Om detta inte är en GET- eller HEAD-förfrågan, förbjuder webbläsaren automatisk omdirigering om inte bekräftat av användaren, eftersom förfrågansvillkoren kan förändras som ett resultat. Notera: Även om RFC 1945 och RFC 2068 specifikationer tillåter inte klienten att ändra förfrågansmetoden när den omdirigerar, många befintliga webbläsare behandlar 302 svar som en 303 svar och använd GET för att komma åt URI:en specificerad i Location, ignorera den ursprungliga förfrågansmetoden. Statuskoder 303 och 307 lades till för att klargöra vad servern förväntar sig från klienten. |
| 303 | svar på den aktuella förfrågan kan hittas på en annan URI, och klienten bör få GET-access till den resursen. Denna metod finns främst för att tillåta skript-aktiverade POST-förfrågans utdata för att omdirigera till en ny resurs. Den nya URI:en är inte en ersättning för referensen till den ursprungliga resursen. Även 303 svar förbjuds att cachas. Naturligtvis kan en andra förfrågan (omdirigering) cachas. Den nya URI:en bör returneras i platsfältet i svaret. Utom om detta är en HEAD-förfrågan, bör svarskroppen innehålla en hyperlänk till den nya URI:en och en kort beskrivning. Notera: Många webbläsare innan HTTP/1.1 förstår inte 303 status korrekt. Om du behöver överväga interaktion med dessa webbläsare, de 302 statuskod bör vara tillräcklig, eftersom de flesta webbläsare hanterar 302 svar exakt på samma sätt som ovanstående specifikation kräver klienten att hantera 303 svar. |
| 304 | Om klienten skickar en villkorlig GET-förfrågan och förfrågan har tillåtts, och dokumentets innehåll inte har ändrats (sedan senaste besöket eller enligt förfrågans villkor), bör servern returnera denna statuskod. 304 svar förbjuds att inkludera meddelandekroppar, så alltid avsluta med den första tomma raden efter huvudet. Svar måste innehålla följande huvudinformation: Uppdateringsdatum, om inte denna server har ingen klocka.
Om servern utan klocka också följer dessa regler, kan proxyservern och klienten lägga till fältet Datum till den mottagna svarshuvudet själva (som specificerats i RFC 2068), och cachningsmekanismen kommer att fungera bra. ETag och/eller Innehåll-Plats, om samma förfrågan skulle ha återkommit en 200-svar. Uppdateringsdatum, Cache-Kontroll, och/eller Vary, om dess värde kan vara annorlunda än värdet som motsvarar andra svar till samma variabel tidigare.
Om detta svarförfrågan använder stark cachevalidering, bör detta svar inte inkludera andra entitetshuvuden; annars (t.ex. en villkorlig GET-förfrågan använder svag cachevalidering), är det förbjudet att inkludera andra entitetshuvuden; detta undviker inkonsekvenser mellan cachade entitetsinnehåll och uppdaterad entitetshuvudinformation. Om en 304 svar indikerar att en entitet för närvarande inte är cacherad, måste cachningssystemet ignorera svaret och skicka upprepade förfrågningar utan begränsningar.
Om en 304 svar mottas för att uppdatera en cachad post, måste cachningssystemet uppdatera hela posten för att återspegla värdena för alla fält som uppdaterades i svaret. |
| 305 | Den efterfrågade resursen måste nås genom den specificerade proxyen. URI-informationen för den specificerade proxyen ges i fältet Location. Mottagaren måste upprepa att skicka en separat förfrågan för att nå den motsvarande resursen genom denna proxy. Endast ursprungsservern kan etablera en 305 svar. Notera: Det finns ingen explicit 305 svar enligt RFC 2068 att omdirigera en enskild förfrågan, och det kan bara etableras av ursprungsservern. Ignorera dessa begränsningar kan leda till allvarliga säkerhetskonsekvenser. |
| 306 | i den senaste versionen av specifikationen, 306 statuskod används längre. |
| 307 | Den efterfrågade resursen svarar nu tillfälligt på förfrågan från en annan URI. Eftersom sådana omdirigeringar är tillfälliga, bör klienten fortsätta att skicka framtida förfrågningar till den ursprungliga adressen. Detta svar kan endast cachas om det anges i Cache-Kontroll eller Uppdateringsdatum. Den nya tillfälliga URI:en bör returneras i svarsfältets Location. Utom om detta är en HEAD-förfrågan, bör den svarande entiteten innehålla en hyperlänk som pekar på den nya URI:en och en kort beskrivning. Eftersom vissa webbläsare inte känner igen 307 svar, behöver ovanstående information läggas till så att användaren kan förstå och begära åtkomst till den nya URI:en.
Om detta inte är en GET eller HEAD-förfrågan, förbjuder webbläsaren automatisk omdirigering om inte användaren bekräftar, eftersom förfrågans villkor kan förändras som ett resultat. |
| 400 | 1. Semantiken är felaktig, och den aktuella begäran kan inte förstås av servern. Utom att ändras, bör klienten inte skicka in begäran upprepade gånger. 2. Begäran är felaktig. |
| 401 | Den aktuella begäran kräver användarautentisering. Svaret måste innehålla en WWW-Autentisera-huvudet för den begärda resursen för att be användaren om information. Klienten kan skicka in en begäran med lämplig Autentiseringshuvudinformation. Om den aktuella begäran redan innehåller Autentisering-certifikat, then 401 svar representerar att servern har avvisat dessa certifikat. Om den 401 svar innehåller samma autentiseringsfråga som föregående svar, och webbläsaren har försökt autentisera minst en gång, då bör webbläsaren visa användaren den entitetsinformation som innehåller svaret, eftersom denna entitetsinformation kan innehålla relevant diagnostisk information. Se RFC 2617. |
| 402 | Denna statuskod är reserverad för möjliga framtida behov. |
| 403 | Servern har förstått begäran, men vägrade att utföra den. skillnad från en 401 svar, autentisering hjälper inte, och begäran bör inte upprepas. Om detta inte är en HEAD-begäran och servern vill kunna förklara varför begäran inte kan utföras, då bör anledningen till avvisningen beskrivas inom entiteten. Naturligtvis kan servern också returnera en 404 svar om den inte vill att klienten ska få någon information. |
| 404 | Begäran misslyckades, och den önskade resursen hittades inte på servern. Det finns ingen information att säga användaren om tillståndet är tillfälligt eller permanent. Om servern är medveten om situationen, the 410 Statuskoden bör användas för att informera den gamla resursen att den är permanent otillgänglig på grund av någon intern konfigurationsmekanism och har ingen adress att hoppa till. The 404 Statuskod används ofta när servern inte vill avslöja varför begäran avvisades eller inget annat lämpligt svar är tillgängligt. |
| 405 | Den efterfrågade metodens i förfrågansraden kan inte användas för att begära den motsvarande resursen. Svar måste returnera ett Allow-huvud som indikerar en lista över förfrågningsmetoder som kan accepteras av den aktuella resursen. Eftersom PUT och DELETE-metoder skriver till resurser på servern, stöder de flesta webbservrar inte eller tillåter inte ovanstående förfrågningsmetod som standard och kommer att returnera en 405 fel för sådana förfrågningar. |
| 406 | Innehållets egenskaper för den efterfrågade resursen uppfyller inte villkoren i förfråganshuvud, så en svarsenditet kan inte genereras. Utom om detta är en HEAD-förfrågan, bör svaret returnera en entitet som tillåter användaren eller webbläsaren att välja de mest lämpliga egenskaperna för entiteten och adresslistan. Formatet för entiteten bestäms av mediatypen definierad i Content-Typhuvud. Webbläsaren kan göra det bästa valet baserat på formatet och sina egna förmågor. Emellertid definierar specifikationen inga kriterier för att göra sådana automatiska val. |
| 407 | Liknande med 401 svar, förutom att klienten måste autentisera på proxyservern. Proxyservern måste returnera en Proxy-Autentisera för autentisering. Klienten kan returnera en Proxy-Autentiseringshuvud för autentisering. Se RFC 2617. |
| 408 | Förfrågan översteg tidsgränsen. Klienten fullföljde inte att skicka en förfrågan inom den tid som servern var redo att vänta. Klienten kan skicka in förfrågan igen vid vilket tillfälle som helst utan några ändringar. |
| 409 | Försöket kan inte slutföras på grund av en konflikt med den aktuella tillståndet för den efterfrågade resursen. Denna kod får endast användas om användaren antas kunna lösa konflikten och kommer att skicka in en ny förfrågan. Svar ska innehålla tillräcklig information för att användaren ska kunna upptäcka källan till konflikten. Konflikter inträffar vanligtvis i behandlingen av PUT-förfrågningar. Till exempel, i en version-granskad miljö, om versioninformationen som är bifogad till en PUT-inlämnade ändringsbegäran för en viss resurs kolliderar med en tidigare (tredje-part) begäran, servern bör returnera en 409 felmeddelande till användaren att begäran inte kunde slutföras.
På detta tidspunkt är det troligt att svarens entitet innehåller en jämförelse av skillnader mellan de två kolliderande versionerna, så att användaren kan skicka in den sammanslagna versionen. |
| 410 | Den efterfrågade resursen är inte längre tillgänglig på servern och har ingen känd vidareadress. Detta tillstånd bör betraktas som permanent. Om möjligt bör klienten med länkredigeringsförmåga ta bort alla referenser till denna adress med användarens tillstånd. Om servern inte vet eller inte kan fastställa om detta tillstånd är permanent, då en 404 statuskod bör användas. Om inte annat anges är detta svar cachbart. Syftet med 410 svar används huvudsakligen för att hjälpa webbmästaren att underhålla webbplatsen, informera användaren att resursen inte längre är tillgänglig och att serverägaren vill att alla fjärranslutningar till denna resurs ska tas bort.
Denna typ av händelse är vanlig i tid-begränsad, värde-tilläggstjänster. På samma sätt som 410 svar används för att informera klienten att resurser som ursprungligen tillhörde en individ inte längre är tillgängliga på den aktuella serverns webbplats. Naturligtvis är det helt upp till serverägaren att markera alla permanent otillgängliga resurser som' 410 Gone ', och hur lång tid att behålla denna mark. |
| 411 | Servern vägrar att acceptera begäran utan att definiera ett Innehåll-Längdheader. Efter att ha lagt till ett giltigt Innehåll-Längdheader som indikerar längden på kravkroppen, klienten kan skicka in begäran igen. |
| 412 | The server failed to meet one or more of the prerequisites when verifying that they were given in the header field of the request. This status code allows the client side to set prerequisites in the requested metadata (request header field data) when fetching resources, thus preventing the request method from being applied to resources other than what it wants. |
| 413 | The server refuses to process the current request because the request submits more entity data than the server is willing or able to handle. In this case, the server can close the connection to prevent the client side from continuing to send the request. If this situation is temporary, the server should return a Retry-After response header to inform the client side how much time it can try again. |
| 414 | The requested URI is longer than the server can interpret, so the server refuses to service the request. This is rare, and common cases include: A form submission that should have used the POST method becomes a GET method, causing the query string (Query String) to be too long. Redirect URI "black holes", such as each redirect using the old URI as part of the new URI, resulting in the URI being too long after several redirects. The client is trying to attack the server with security bugs that exist in some servers.
This type of server uses a fixed-length buffer to read or manipulate the requested URI. When the parameters after GET exceed a certain value, a buffer overflow may occur, resulting in arbitrary code execution [1]. Servers without such vulnerabilities should return a 414 status code. |
| 415 | For the method of the current request and the requested resource, the entity submitted in the request is not in a format supported by the server, so the request is rejected. |
| 416 | If the request contains a Range header, and any data ranges specified in the Range do not coincide with the available range of the current resource, and the If-Range header is not defined in the request, the server should return a 416 statuskod. Om Range använder en byteomfattning innebär detta att den första bytepositionen för alla dataomfattningar specificerade i förfrågan överskrider längden på den aktuella resursen. Servern bör också inkludera ett Content-Range entity header tillsammans med 416 statuskod för att indikera längden på den aktuella resursen. Detta svar förbjuds också att använda multipart/byteranges som dess Innehåll-Typ. |
| 417 | Det förväntade innehållet som specificerats i förfrågans header Expect kan inte uppfyllas av servern, eller servern är en proxyserver som har tydligt bevis att det förväntade innehållet inte kan uppfyllas på nästa nod i den aktuella ruttens. |
| 421 | Antalet anslutningar till servern från Internetprotokolladressen där den aktuella klienten är belägen överskrider det maximalt tillåtna av servern. Typiskt refererar Internetprotokolladressen här till klientens adress som ser servern (t.ex. användarens gateway eller proxyserveradress). I detta fall kan anslutningsantalet involvera mer än en slutanvändare. |
| 422 | Antalet anslutningar till servern från Internetprotokolladressen där den aktuella klienten är belägen överskrider det maximalt tillåtna av servern. Typiskt refererar Internetprotokolladressen här till klientens adress som ser servern (t.ex. användarens gateway eller proxyserveradress). I detta fall kan anslutningsantalet involvera mer än en slutanvändare. |
| 422 | Förfrågan var korrekt formaterad, men kunde inte besvara på grund av en semantisk fel. (RFC 4918 WebDAV) 423 Låst Den aktuella resursen är låst. (RFC 4918 WebDAV) |
| 424 | Den aktuella förfrågan misslyckades på grund av ett fel i en tidigare förfrågan, såsom PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definierad i WebDav-avancerade samlingar utkast, men inte i WebDAV-sekventiella sets protokoll (RFC 3658). |
| 426 | Klienten bör byta till TLS/1.0. (RFC 2817) |
| 449 | Utökad av Microsoft, förfrågningar bör försökas om efter att ha utfört lämpliga åtgärder. |
| 500 | Servern stöter på en oväntad situation som förhindrar den från att slutföra förfrågan. Generellt sett uppstår detta problem när serverns kod misslyckas. |
| 501 | Servern stöder inte en funktion som krävs av den aktuella förfrågan. När servern inte kan känna igen den förfrågade metoden och inte kan stödja sin förfrågan om någon resurs. |
| 502 | När en server som fungerar som en gateway eller proxy försöker utföra en förfrågan, får den ett ogiltigt svar från en upptagningsserver. |
| 503 | Servern kan för närvarande inte bearbeta begäran på grund av tillfällig serverunderhåll eller överbelastning. Detta tillstånd är tillfälligt och kommer att återställas efter en tid. Om fördröjningstiden kan förutses, kan svaret inkludera en Retry-Efter header för att indikera fördröjningstiden. Om denna Retry-Efter information inte ges, klienten bör behandla den som om den var en 500-svar. Notera: Existensen av en 503 statuskod innebär inte att servern måste använda den vid överbelastning. Vissa serverar vill helt enkelt vägra klientens anslutning. |
| 504 | När en server som fungerar som gateway eller proxy försöker utföra en begäran, misslyckas den att få ett svar från en upptagningsserver (identifierad av URI, som HTTP, FTP, LDAP) eller en sekundär server (som DNS) i enlighet med tiden. Notera: Vissa proxyserver returnerar en 400 eller 500-fel när DNS-frågan timeout |
| 505 | Servern stöder inte, eller vägrar att stödja, versionen av HTTP som används i begäran. Detta innebär att servern inte kan eller kommer inte att använda samma version som klienten. Svar bör inkludera en entitet som beskriver varför versionen inte stöds och vilka protokoll servern stöder. |
| 506 | Utökad av Transparent Content Negotiation Protocol (RFC 2295), detta representerar en intern konfigurationsfel på servern: den efterfrågade förhandlingsvariabeln resurs är konfigurerad att använda sig själv i en transparent innehållsförhandling, och därför är det inte ett lämpligt fokus i en förhandlingsprocess. |
| 507 | Servern kan inte lagra innehållet som är nödvändigt för att slutföra begäran. Detta tillstånd betraktas som tillfälligt. WebDAV (RFC 4918) |
| 509 | Servern har nått bandbreddslimiten. Detta är inte en officiell statuskod, men det används fortfarande widely. |
| 510 | Policyerna som krävs för att få tillgång till resurser uppfylls inte. (RFC 2774) |
