This document:Public document·View comments·Disposition of Comments·
Nearby:Mobile Web Best Practices Working Group Other specs in this tool Mobile Web Best Practices Working Group's Issue tracker
Quick access to LC-2267 LC-2268 LC-2269 LC-2270 LC-2289 LC-2316 LC-2317 LC-2318 LC-2319 LC-2320 LC-2321 LC-2322 LC-2323 LC-2324 LC-2327 LC-2328 LC-2329 LC-2358 LC-2359 LC-2360
Previous: LC-2321 Next: LC-2327
Francois Daoust wrote: > For clarification, the guidelines do not build on the assumption that > GET is not safe. > > The mechanism described by Luca is actually recommended by the > guidelines: send a GET with original headers, then send a request with > modified headers if the first response is a "request unacceptable" > response. Francois, this is not what I meant. What I meant is "content tasting". Proxies should send a GET with original headers and if they get a response (which they probably will), they should smell the response and figure out whether that content may be good enough for mobile (and err on the side of assuming it is). If the content is likely to be OK for a mobile device, no transcoding should take place at all. This is explicitly ruled out by 4.1.5.1: http://www.w3.org/TR/ct-guidelines/#sec-content-tasting "The theoretical idempotency of GET requests is not always respected by servers. In order, as far as possible, to avoid misoperation of such content, proxies *should* avoid issuing duplicate requests and specifically *should not* issue duplicate requests for comparison purposes." There was no reason to add this part, except, as I mentioned in my first message, to help novarra, whose transcoder does not behave this way. Luca