Re: SVG 1.2 12.1.1 The Progress Event

On Wednesday, June 4, 2003, 3:06:39 PM, Tobias wrote:


TR> Jim Ley wrote:


>> I can't believe I'm unique in serving up 404 jpegs! * Squiggle especially
>> needs 404's to be content-negotiated, to something it can understand, rather
>> than the traditonal .  (there's a similar situation with HTTP 302/307 status
>> which RFC 2616 says "The entity of the response SHOULD contain a short
>> hypertext note with a hyperlink to the new URI(s)" - but doesn't suggest
>> what mark-up language I should use for that note.)


TR> For hypertext (which SHOULD be used according to that RFC), I suggest 
TR> the one called HyperText Markup Language.

TR> But I agree that it makes sense to serve other versions if the UA 
TR> doesn't accept (X)HTML. So if a UA like Squiggle says it doesn't accept 
TR> HTML, my server should ask what it would prefer,

Yes and no.

For a request, yes. (And I assume that all SVG UAs send an accept
header with image/svg+xml, image/png and image/jpeg. Which implies
that they should get back a 406 Not Acceptable if they visit an HTML
page for example, unless they also do html and advertise this in the
accept header).

/me adds 'test http headers of SVG user agents' to someday pile.

For a response, where the actual information is the response code and
the body might not even be shown, it seems odd to send back a 'none
acceptable' plus you would then need two response codes on the one
response.

Really, I think the http spec is suggesting a belt and braces approach
where the use gets a chance to proceed onto the correct document if
the user-agent has a poor http implementation (on the assumption that
UA=html 2 at least UA).

The assumption that 'everything' is an html browser and can accept
non-well-formed content (ie, all HTML before XHTML, which is not well
formed even when it is valid) is one of those historical accidents
that was reasonable at the time but turns out to be false.


TR> and serve that. In this case, SVG for example (which is more
TR> accessible than JPEG in many if not most cases).

Sending an SVG body on your 302 response is fine, if the accept
headers indicate that SVG is accepted. Sending a further query to ask
which formats are available (eg 300 Multiple Choices or 406 Not
Acceptable) throws away the actual response code.

My reading of the HTTP/1.1 spec indicates that its better to give a
blank body or an HTML body, rather than loose the real response code
in an attempt to negotiate an acceptable format in this situation. The
UA is not required to display the body, just to act on the status
code.



-- 
 Chris                            mailto:chris@w3.org

Received on Saturday, 7 June 2003 10:52:35 UTC