Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-12 Thread Windy Road

Hi,

So it appears that there are no plans to implement feature negotiation
in Apache at this point in time.  I'm willing to look into modifying
mod_negotiation to support some level of feature negotiation if
someone is willing to implement something on the WebKit side.  Anyone
interested?

Cheers,

--
Tom Howard
http://windyroad.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-11 Thread Windy Road

Hi,

Does Apache support Feature negotiation as specified in RFC 2295
(see http://www.ietf.org/rfc/rfc2295 )?

If so, is there any documentation related to this (I couldn't find any)?

If not, are there any plans to support this portion of the RFC?

FYI the back story to this request is from a discussion regarding
having images served to a client dependant on its resolution and/or
viewport width. Normal browsers may get an the image as 600px across,
small screen devices may get an image that is 150px across and browser
requesting the image for printing purposed may get an image that is
1200px across.

I was able to create a type-map file for the images as follows:

URI: image

URI: image-1200x1000.jpg
Content-type: image/jpeg; qs=0.9

URI: image-600x500.jpg
Content-type: image/jpeg; qs=0.5

URI: image-300x250.jpg
Content-type: image/jpeg; qs=0.25

URI: image-150x125.jpg
Content-type: image/jpeg; qs=0.1

Apache would (correctly) perform server side selection to pick the
variant with the highest qs, however I could not find any way of
specifying features (such as DPI) for each variant, that would allow a
lower qs variant to be selected based on a appropriate request with
Accept-Features (e.g. Accept-Features: dpi=[70-100]).

Cheers,

--
Tom Howard
http://windyroad.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-08 Thread Peter Speck


On 07/06/2007, at 22:38, Maciej Stachowiak wrote:

The only case that needs to be addressed better IMO is foreground  
images via img. And that should probably be handled at the HTML  
or CSS level, not the HTTP level.


But the html doesn't know (today) which dpi the display is using.  
When the server generates the html file to the client, it doesn't  
know the resolution either. So do you imaging adding Javascript  
properties to dynamically update img or do you want to add new  
attributes to the img tag?  Or should we replace all of them with  
div's using backgrounds?


Rather than hacking img with special attributes for resolution, I  
consider Accept-Resolution a generalized solution rather than using  
one method for css backgrounds, another for img, and then another  
for object including images that Flash movies might fetch.




   - Peter Speck


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-08 Thread Nicholas Shanks

Hi Peter.

I recommend you take a look at what Larry Masinter pointed out. It  
becomes clear that all of this has already been solved 9 years ago,  
but because it (apparently) isn't enabled in Apache by default, I and  
many others never even realised it existed:



Content negotiation for HTTP based on parameters beyond MIME types
was the focus of a significant amount of IETF work, including
RFC 2295 (Transparent Content Negotiation in HTTP)
RFC 2296 (HTTP Remote Variant Selection Algorithm -- RVSA/1.0)
and a set of 'media features' (including resolution, screen
size, pixel depth, etc.) in a Media Feature registry
(RFC 2506, BCP 31).


http://www.ietf.org/rfc/rfc2295

Basically the client adds a Negotiate: trans header to the GET  
request, and initiates transparent (to the user) content negotiation  
(TCN). The server sends back a 300 response with a list of choices in  
an Alternates header, the format of which is defined in the RFC. The  
client then issues a new GET request for the one it wants, without  
having to send any environment information (dpi, c.) to the server.


Clients can also send a few (small) Accept-* headers and ask the  
server to take an educated guess, but still return the list of  
Alternates along with it's guess, which could save round trips if the  
client decides that the server's guess was good enough (the 150dpi  
would have been best for me, but I'll just use this here 200dpi image  
you've already sent). If the resource is non-negotiable, the  
Negotiate header is ignored by the server and nothing changes.



In light of this, I suggest that WebKit developers (including me if I  
get the time) look into implementing this set of RFCs, and ignore all  
previous suggestions.
It seems we've been in the classic chicken-and-egg situation since  
1998, where clients don't implement it because servers don't have it  
turned on by default, and servers don't have it enabled because there  
are no client implementations to test against. Website owners are  
left none the wiser, and while a few server-side negotiation, most  
don't find it reliable enough to use, and have things like flag icons  
on their home page to choose your language.


Apple members should discuss with the IETF the addition of device- 
pixel-ratio to the Media Feature registry. This will allow TCN for  
img and object elements containing visual media, and anywhere  
else where CSS does not apply.
I also suggest a High-Res: Part III blog post on webkit.org to draw  
attention to this feature and get more web developers aware of and  
using TCN, which I think is the biggest hurdle (implementing it won't  
be as hard).


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-08 Thread Peter Speck


On 08/06/2007, at 13:07, Nicholas Shanks wrote:


http://www.ietf.org/rfc/rfc2295
[...]
In light of this, I suggest that WebKit developers (including me if  
I get the time) look into implementing this set of RFCs, and ignore  
all previous suggestions.
It seems we've been in the classic chicken-and-egg situation since  
1998, where clients don't implement it because servers don't have  
it turned on by default, and servers don't have it enabled because  
there are no client implementations to test against.

[...]

Apple members should discuss with the IETF the addition of device- 
pixel-ratio to the Media Feature registry. This will allow TCN for  
img and object elements containing visual media, and anywhere  
else where CSS does not apply.


This sounds good. I've read the RFC and cannot find any problems, so  
I dully agree to drop prior proposals. What's the ETA for WebKit  
implementation?



   - Peter Speck


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-08 Thread Rob Burns

Hi Nicholas and Peter,

That is great (though ironic) to hear that this feature's been there  
all along (at least in the spec and in the server). I wonder if you  
(Nicholas) could write up or point to some instructions on  
configuring that in Apache (ideally the exact lines to add to the  
config filie).  This would help implementors and just help raise  
awareness for server admins (as the word spreads).


I think the device-pixel-ratio is not really needed in the registry.  
Its a bit of a sidetrack issue.. If design is done through resolution- 
independent units (everything but pixels) and only bitmaps are  
measured in pixels, the difference between device pixels and CSS  
pixels disappears. In other words, the work of some of the proposals  
in CSS 2.1 and the Acid2 tests basically turns pixel into 1/96th of  
an inch (with complicating caveats about much higher resolution  
output devices and viewing angle). All of this means that pixels  
should just not be used except to describe the resolution or  
dimensions of a bitmap image.


The units in an NSView are typically understood as points. In WebKit  
they're understood as pixels instead (which probably became necessary  
to match the scale of page designs to other competing browsers).  
Until resolution independence is finally introduced into Mac OS X the  
two are equivalent so there's no disjoint. As display resolution's  
have increased, the base zoom of displays has decreased. This means  
that with a 96dpi display, the base zoom is at  75% (72/96 =0.75).  
When resolution independence is introduced, the base zoom can be  
whatever the user wants. NSView units will be points in other  
applications, but NSView units will be CSS2.1 pixels (1/96 of an  
inch) in WebKit (which is why one has to scale down by 75%  to turn  
units that are 1-1/3 of a point back into 1 point when printing  
because then the base zoom is expected to be 100% ). Anyway, as I  
said, this was probably necessary just to keep the scale similar to  
other browsers. Otherwise everyone would be asking why pages were so  
much smaller in WebKit than in every other browser (plus, I'm not so  
sure the road to resolution independence was clearly paved when  
WebKit was brought to Mac OS X).


So perhaps some of this could be illustrated on the blog.

* The different treatment of resolution independence in WebKit  
compared with other Mac OS X apps (NSView units are 1/96 of an inch  
and not 1/72)
* The importance of using resolution independent units (not pixels)  
is important. Pixels were bad to use before for CSS. The treatment by  
IE and Acid2 as a fixed 1/96 of an inch (and therefore an absolute  
unit) renders pixels as quasi resolution independent. But that just  
creates confusion (hence the difference between the terms CSS pixel  
and  device pixel). If we really need a term for 1/96 of an inch  
perhaps someone could coin an neologism for it (I'm  not even going  
to try :-) ).
* Finally, including the Apache configuration to make that convenient  
for server admins and browser developers for testing (after all, as  
Nicholas said the reason we thought we had to reinvent the wheel is  
that Apache didn't include this in the standard configuration).  
Getting Apple and other Apache distributors to add this to the config  
file (even if commented out) would be a good approach.


Take care,
Rob

On Jun 8, 2007, at 6:07 AM, Nicholas Shanks wrote:


Hi Peter.

I recommend you take a look at what Larry Masinter pointed out. It  
becomes clear that all of this has already been solved 9 years ago,  
but because it (apparently) isn't enabled in Apache by default, I  
and many others never even realised it existed:



Content negotiation for HTTP based on parameters beyond MIME types
was the focus of a significant amount of IETF work, including
RFC 2295 (Transparent Content Negotiation in HTTP)
RFC 2296 (HTTP Remote Variant Selection Algorithm -- RVSA/1.0)
and a set of 'media features' (including resolution, screen
size, pixel depth, etc.) in a Media Feature registry
(RFC 2506, BCP 31).


http://www.ietf.org/rfc/rfc2295

Basically the client adds a Negotiate: trans header to the GET  
request, and initiates transparent (to the user) content  
negotiation (TCN). The server sends back a 300 response with a list  
of choices in an Alternates header, the format of which is defined  
in the RFC. The client then issues a new GET request for the one it  
wants, without having to send any environment information (dpi,  
c.) to the server.


Clients can also send a few (small) Accept-* headers and ask the  
server to take an educated guess, but still return the list of  
Alternates along with it's guess, which could save round trips if  
the client decides that the server's guess was good enough (the  
150dpi would have been best for me, but I'll just use this here  
200dpi image you've already sent). If the resource is non- 
negotiable, the Negotiate header is ignored by the 

Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-07 Thread Maciej Stachowiak


On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote:

It has been mentioned on the Safari WebKit development mailing list  
that a HTTP header which specified a document's target resolution  
would be useful to allow clients to negotiate for high-res or low- 
res artwork and CSS referring to such (background-image, and the  
like), depending on their screen pixels, printer resolution, etc.


I don't think it's a good idea to handle this at the HTTP level,  
because that requires server-side changes and approaches are possible  
which handle things purely on the client side.



I would like to propose this to the Working Group.
My ideas are as follows:


The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi


This is a bad idea for a number of reasons:

1) CSS already has media queries to select from multiple stylesheets  
in HTML/XML, or to select from multiple blocks in a single stylesheet.


2) DPI is not really the relevant factor to make the decision, what's  
important is the UI scale factor. If I'm running at 144 DPI but at 1x  
scale, I want the same images as at 72 dpi 1x scale.


3) Passing the resolution to the server forces the selection logic to  
be on the server side, not the client. But that's not really sensible  
- if the server has multiple  resolution versions of a resource, such  
as an image, it should advertise them to the client and let the client  
choose. For example, at 1.5 UI scale factor, if the server has 3x and  
2x images available the client could reasonably choose 2x (the next  
scale up) or 3x (since it is an integer multiple of the scale factor).





The server has the following to choose from:

default.72dpi.css
default.144dpi.css
default.288dpi.css
default.2400dpi.css


In this instance, the 144 DPI stylesheet would be returned, because  
it is the next size up, with a header:


Content-Resolution: 144 dpi

The client would thus know there was a resolution mis-match and  
(optionally) perform a correction on the CSS values.
(the mechanism assumes higher is better, and scaling down is  
preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
resolution of 160dpi, and so would get the 288dpi stylesheet, even  
though the 144 is a closer match, and the laptop with a web page  
zoom of 200% would request 233.33 dpi)


This doesn't make sense with the way clients actually work. What you  
care about with images embedded in web content is the relative scale  
of CSS pixels relative to device pixels, which does not have any  
necessary direct relation to the physical DPI. You don't actually want  
to serve different images to different DPI screens if they are both  
running at the same scale factor.





Furthermore:

• Images served with a Content-Resolution header could have their  
resolution trusted (most web browsers today display one pixel on  
screen per pixel in the bitmap, and ignore the image's internal  
resolution parameter, if one exists). If they don't match, probably  
best to use the image's internal one. There could also be a special  
Content-Resolution: auto-adjust header meaning that the server  
doesn't know the resolution at content-negotiation time, but wants  
the client to scale it according to the image's internal value  
anyway, and not do a pixel-to-pixel mapping.


• A dpcm (dots per centimetre) parameter could also be understood  
by both ends and converted as necessary.



What do people think? I've only spent an hour or so pondering this,  
so it won't be bulletproof yet.


I think the whole design of it is wrong. It's based on DPI instead of  
scale factor, it pushes the decision to the server when it should be  
made on the client side, and it handles things at the HTTP level that  
should be (and indeed are) handled by CSS media queries.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-07 Thread Maciej Stachowiak


On Jun 7, 2007, at 9:00 AM, Nicholas Shanks wrote:


Sorry,


Accept-Content: text/css, text/dsssl, text/xsl


should of course have referred to Accept-Type  :-)


Actually it should have been Accept:. There is no Accept-Type header.

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-07 Thread Rob Burns

Macej,

I think you misunderstand the proposal. It does take scale factor  
into account. It also is meant to handle other cases (not just CSS).  
I do think you're right about the server advertising the  
possibilities, but that would probably complicate things a lot. In  
any case its better than simply getting a one-size-fits all bitmap  
image.


Take care,
Rob

On Jun 7, 2007, at 2:58 PM, Maciej Stachowiak wrote:



On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote:

It has been mentioned on the Safari WebKit development mailing  
list that a HTTP header which specified a document's target  
resolution would be useful to allow clients to negotiate for high- 
res or low-res artwork and CSS referring to such (background- 
image, and the like), depending on their screen pixels, printer  
resolution, etc.


I don't think it's a good idea to handle this at the HTTP level,  
because that requires server-side changes and approaches are  
possible which handle things purely on the client side.



I would like to propose this to the Working Group.
My ideas are as follows:


The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi


This is a bad idea for a number of reasons:

1) CSS already has media queries to select from multiple  
stylesheets in HTML/XML, or to select from multiple blocks in a  
single stylesheet.


This is meant for a more flexible approach that also works outside CSS.



2) DPI is not really the relevant factor to make the decision,  
what's important is the UI scale factor. If I'm running at 144 DPI  
but at 1x scale, I want the same images as at 72 dpi 1x scale.




Don't you mean 0.5x scale?

3) Passing the resolution to the server forces the selection logic  
to be on the server side, not the client. But that's not really  
sensible - if the server has multiple  resolution versions of a  
resource, such as an image, it should advertise them to the client  
and let the client choose. For example, at 1.5 UI scale factor, if  
the server has 3x and 2x images available the client could  
reasonably choose 2x (the next scale up) or 3x (since it is an  
integer multiple of the scale factor).




This is a valid issue, but perhaps it could be addressed in the  
proposal. Its better than the alternative of no non-css approach.  
However, keep in mind that In a purse CSS environment, the author  
doesn't take into consideration the processing needs off the client  
anymore than the server does. The CSS (written by the author) will  
determine which pixel dimension image the client gets).


This doesn't make sense with the way clients actually work. What  
you care about with images embedded in web content is the relative  
scale of CSS pixels relative to device pixels, which does not have  
any necessary direct relation to the physical DPI. You don't  
actually want to serve different images to different DPI screens if  
they are both running at the same scale factor.


I think you're saying the same thing in different language. Both Mac  
OS X and CSS were designed with resolution independence in mind. The  
distinction over devise pixels and CSS pixels merely muddies the  
issue. An image that's specified to be 4 inches square on a 96dpi  
display at 50% zoom is 192 pixels square (however you want to say  
it). Getting that pixel dimension image delivered form the server is  
what we're looking for (or perhaps a different pixel dimension if the  
client expects a resizing or immediate printing).



I think the whole design of it is wrong. It's based on DPI instead  
of scale factor, it pushes the decision to the server when it  
should be made on the client side, and it handles things at the  
HTTP level that should be (and indeed are) handled by CSS media  
queries.


I think you should take another look at it. Your objections don't  
really address the proposal.


Take care,
Rob
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-07 Thread Andre-John Mas
Surely all of this becomes moot if we specify objects in terms of  
inches, cm or mm, all of which are already supported by css? A  
browser that interprets these 'absolute' units properly should  
already know what DPI the current environment is in, or have access  
to the necessary API to display correctly.


The problem that we have today is that some environments don't tell  
the application the real DPI, so the application is left guessing and  
mis-rendering things on screen.


The other thing that must be taken account is that on a multi-headed  
computer you may have two screens each with different DPIs. If you  
were to send DPIs to a server, which one would you use? It is for  
reasons such as this, that I believe, that it is important that it  
the responsibility of the local system to work this out, with the  
appropriates hints from the web page.


Andre

On 7-Jun-07, at 16:38 , Maciej Stachowiak wrote:



On Jun 7, 2007, at 1:26 PM, Rob Burns wrote:


Macej,

I think you misunderstand the proposal. It does take scale factor  
into account. It also is meant to handle other cases (not just  
CSS). I do think you're right about the server advertising the  
possibilities, but that would probably complicate things a lot.


It can be done in the CSS file for CSS backgrounds using media  
queries, this allows things to work without any server-side  
changes. The only case that needs to be addressed better IMO is  
foreground images via img. And that should probably be handled at  
the HTML or CSS level, not the HTTP level.


In any case its better than simply getting a one-size-fits all  
bitmap image.


The scale factor is the only thing that *actually* matters. The DPI  
is irrelevant. (And as Hyatt pointed out, the actual scaling an  
image gets might depend on the specific context in the page.)


 - Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-07 Thread Rob Burns


On Jun 7, 2007, at 3:52 PM, Andre-John Mas wrote:

Surely all of this becomes moot if we specify objects in terms of  
inches, cm or mm, all of which are already supported by css? A  
browser that interprets these 'absolute' units properly should  
already know what DPI the current environment is in, or have access  
to the necessary API to display correctly.


The problem that we have today is that some environments don't tell  
the application the real DPI, so the application is left guessing  
and mis-rendering things on screen.


The other thing that must be taken account is that on a multi- 
headed computer you may have two screens each with different DPIs.  
If you were to send DPIs to a server, which one would you use? It  
is for reasons such as this, that I believe, that it is important  
that it the responsibility of the local system to work this out,  
with the appropriates hints from the web page.




It seems that you're not reading the proposal.  This does call for  
the client to use whatever algorithm it deems appropriate to request  
an image of a certain pixel dimension (though I think my copy of  
Nicholas example may have read ppi, I meant to list pixel dimension).  
In any event, the server works to accommodate the client.  This isn't  
meant to help the client determine the absolute dimensions its meant  
to deliver efficiently sized content. If its too large, it waists  
bandwidth (at a UI responsiveness degrading moment) and then gets  
down-sampled by the client anyway. If its too small, it may look  
poor. CSS will not solve this (except for CSS related images). It  
needs content negotiation. And even for CSS with media queries, this  
is even more flexible.


Also, as I said before media queries do not accomplish what you're  
saying they accomplish. They don't leave things in the hands of the  
client, they're in the hands of the author. So if the author (maybe  
years before), decides to deliver an image of a certain size to the  
client, that's what the client gets. WebKit isn't going to be able to  
request a different size. Presumably the authro will make it  
appropriate for the client (based on the media query), but the author  
does no necessarily know anymore about WebKit's image processing  
capabilities (whether it prefers an image twice the size to one a  
little smaller than the requested size). So the solution proposed  
here actually puts more control in the clien't's hands than CSS media  
queries (unless the client starts lying about its meda environment,  
but I don't think that would be good practice).


Take care,
Rob.

PS, again my suggestion is for the client to request specific pixel  
dimensions for the media not the ppi/dpi/cmpi) If the the UA is in an  
environment with multiple displays or multiple resolution output of  
any kind it can use that in determining the pixel dimensions to  
request. Otherwise, it can re-request the image for the new output  
device..

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-07 Thread Nicholas Shanks

On 7 Jun 2007, at 23:07, Rob Burns wrote:

PS, again my suggestion is for the client to request specific pixel  
dimensions for the media not the ppi/dpi/cmpi) If the the UA is in  
an environment with multiple displays or multiple resolution output  
of any kind it can use that in determining the pixel dimensions to  
request. Otherwise, it can re-request the image for the new output  
device..


Yeah, your earlier example used ppi, not dimensions. Could you please  
provide a new example of what you envisage, with all the relevant  
back-and-forth headers enumerated, although I think what I suggest  
below is better than sending any pixel data to the server. Let me  
know what you think on this, Rob:



On my previous CHOICES suggestion:

Thinking further about caching, creating a new request type that was  
a hybrid of GET and HEAD was a bad idea. A better way would be to use  
GET but supply a new header that disables content negotiation (which  
is what I was really trying to do, though I didn't quite realise it),  
forcing a 406 if any content negotiation would otherwise have been  
performed. The 406 would then be automatically handled (not presented  
to the user). It puts all choice in the hands of the client/user and  
not the server/author.


I expect it would go something like:

Negotiation: disable


So what happens now still works:

Old client requests image /foo and provides no disabling header
Server sends back 'optimum' resource foo, as best it can determine,  
taking into account quality-of-source and file length

Object is cached by proxy
Client uses result returned


New behaviour also works:

New client requests /foo and asks for content negotiation to not  
occur by including a new header.

Server responds without negotiation because there's only one choice.
Response is cached as normal by proxy.
Result is used by client.

-or-

New client requests /foo and asks for content negotiation to not  
occur by including a new header.
Server detects multiple resources to choose from, sends back a 406  
immediately

Result is not cached by intermediate proxies.
	(A smart proxy could even clear it's cache whenever it sees a URI  
return a 406,
	as it now knows that there are multiple representations for that  
resource and

that it's previous cached object would not be valid for all clients!)
Client parses (scrapes) the 406 response body (which will have to be  
more clearly spec'ed)
Client issues a new request for the choice it wants, using exact URI,  
can omit new header this time

Server responds without negotiation because there's only one choice.
Response is cached as normal by proxy.
Result is used by client.


The cost is one round-tip to the server per negotiable URI + one  
header on all initial resource requests.

The saving is no need to send any Accept-* headers anymore.


So basically:
• Content negotiation is a good thing for users
• Server-side negotiation defeats caching and gets so long-winded  
that usually a wildcard is sent anyway (e.g. Accept-Encoding)
• Client-side negotiation allows caching of the final URI, as long as  
the negotiable URI is not cached and a bad choice returned by the proxy.
• Client-side negotiation can be transparent to the user, a 406  
response doesn't need to be presented
• This can all be implemented as an extension to HTTP 1.1, and in a  
future version of HTTP, the new header can be made implicit.
• Whilst there could also be a Negotiation: enable for HTTP 1.2 or  
2.0, simply sending the Accept-* headers would be enough to indicate  
that you wanted server-side negotiation.
• The response could also include a Suggest-Location: header for  
clients that aren't able to/don't want to parse the choices and  
select one. This would probably be what the server would have picked  
if it had done negotiation anyway.
• Also, a new response code (418 Client Selection Required) could be  
used instead of a 406, with an XML body that the client is not  
allowed to show to the user. This would be much better than scraping  
a 406, more extensible in future etc etc. Clients without an XML  
parser just use the server's suggestion.



- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-07 Thread Nicholas Shanks

sorry for more spam people :-)
a couple of things i don't have time to write about before i go to  
bed (tis gone 1am here)



http code 300 is what i was wanting, not 406 or making up a new one
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1

the Suggest-Location param already exists, and is just called  
Location

(same url)

agent-driven negotiation is already suggested by HTTP 1.1:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
except that:
	1) the format of a 300 response is not defined and in fact doesn't  
make it clear whether UAs should look in the headers or body for the  
list of choices
	2) there seems to be no way to make apache (v1.3) generate a 300  
response, it does server-side negotiation with all the things i tried  
(which is where my new header would apply - make it generate a 300!).
	3) i've never seen a 300 response from any web server in the wild.  
if it's not even implemented, i'm not surprised no client apps do  
their own negotiation.



I am intrigued by what larry just write, and will look at it either  
tomorrow or in 10 days, as am away next week.
i'm sure all the HTTP boffins already knew this and are lookin  
skyward right now. sorry folks!


- Nicholas.




smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev