- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 15 Jun 2008 07:25:07 +0000
- To: www-validator-cvs@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=785 --- Comment #25 from Etienne Miret <elimerl@gmail.com> 2008-06-15 07:25:07 --- Created an attachment (id=555) --> (http://www.w3.org/Bugs/Public/attachment.cgi?id=555) Forwards Accept, Accept-Charset and Accept-Language headers in a referer request This patch makes use of the already available "accept", "accept-language" and "accept-charset" parameters and populate them with the values provided by the client *in case of a referer request*. It will also make sure those values are kept across revalidation. This makes URI to be very long. Sorry. The headers sent by the client are copied verbatim, that means that the validator will send Accept and Accept-Charset headers with types and charset it doesn’t support. This is the desired behaviour since a check/referer link on a - say - PDF document should trigger an error "This document type cannot be validated" even if a HTML/XHTML variant is available. No Accept-Encoding header is sent because in case the validator gets an encoding it doesn’t know about, it tries to validate the encoded document. This is different from charset and content-type, where the validator will display an appropriate error message whenever it gets one it doesn't know about. Beside Accept-Encoding, a server may do content-negotiation with any HTTP header, notably User-Agent, and even other informations (like IP address). Hence, there is no, and there cannot be any warranty that the validated document is the one the user was actually viewing, although this patch will help this. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Sunday, 15 June 2008 07:25:47 UTC