From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:06
Almost 2 months ago we discussed about gitweb not properly detecting the
client's ability to deal with application/xhtml+xml, something to do
with the caching of a previous request from a client which did support
it and serving the same content to a subsequent client which does not.
Right now www.kernel.org/git is unusable for me with lynx as it keeps
prompting:
application/xhtml+xml D)ownload, or C)ancel
Is there any plan to have that fixed?
Nicolas
On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:
Almost 2 months ago we discussed about gitweb not properly detecting the
client's ability to deal with application/xhtml+xml, something to do
with the caching of a previous request from a client which did support
it and serving the same content to a subsequent client which does not.
I apparently missed that entire conversation, my apologies.
Right now www.kernel.org/git is unusable for me with lynx as it keeps
prompting:
application/xhtml+xml D)ownload, or C)ancel
Is there any plan to have that fixed?
Well there are a couple of quick thoughts, so far (in my quick testing)
lynx and IE are the only two browsers that have issues with this
particular bit of code. Links, konqueror, safari, firefox, mozilla, etc
all seem to handle the pages without issue. Taking a quick glance at
the code it seems IE claims to be xhtml+xml compliant but apparently
isn't really (any real surprise?) and lynx just doesn't seem to support
that mime type.
The simplest fix would be to eliminate the distinction between
applicatoin/xhtml+xml and application/html in the gitweb code (or at
least in the caching gitweb code) and have everything claim a mimetype
of application/html and let the browser sort out if it's using xhtml or
html from the doctype. This would solve both the problem your seeing on
lynx and would make the caching gitweb usable by more IE users.
Some quick testing on my part seems to indicate this doesn't break
behavior for any of the clients I have access to, but I thought I'd
check and see if anyone had any concerns over this particular change
before I barrel ahead with it in the caching gitweb code.
- John 'Warthog9' Hawley
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:06
On Sun, 22 Apr 2007, J.H. wrote:
On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:
quoted
Almost 2 months ago we discussed about gitweb not properly detecting the
client's ability to deal with application/xhtml+xml, something to do
with the caching of a previous request from a client which did support
it and serving the same content to a subsequent client which does not.
I apparently missed that entire conversation, my apologies.
quoted
Right now www.kernel.org/git is unusable for me with lynx as it keeps
prompting:
application/xhtml+xml D)ownload, or C)ancel
Is there any plan to have that fixed?
Well there are a couple of quick thoughts, so far (in my quick testing)
lynx and IE are the only two browsers that have issues with this
particular bit of code. Links, konqueror, safari, firefox, mozilla, etc
all seem to handle the pages without issue.
No. You also missed that links, elinks, and the emacs one (w3m or the
like) were also reported to fail. And sometimes lynx even works.
Taking a quick glance at the code it seems IE claims to be xhtml+xml
compliant but apparently isn't really (any real surprise?) and lynx
just doesn't seem to support that mime type.
Lynx and many others. It is just a question of luch whether the served
page is acceptable or not.
The simplest fix would be to eliminate the distinction between
applicatoin/xhtml+xml and application/html in the gitweb code (or at
least in the caching gitweb code) and have everything claim a mimetype
of application/html and let the browser sort out if it's using xhtml or
html from the doctype. This would solve both the problem your seeing on
lynx and would make the caching gitweb usable by more IE users.
On Sun, 2007-04-22 at 21:16 -0400, Nicolas Pitre wrote:
On Sun, 22 Apr 2007, J.H. wrote:
quoted
On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:
quoted
Almost 2 months ago we discussed about gitweb not properly detecting the
client's ability to deal with application/xhtml+xml, something to do
with the caching of a previous request from a client which did support
it and serving the same content to a subsequent client which does not.
I apparently missed that entire conversation, my apologies.
quoted
Right now www.kernel.org/git is unusable for me with lynx as it keeps
prompting:
application/xhtml+xml D)ownload, or C)ancel
Is there any plan to have that fixed?
Well there are a couple of quick thoughts, so far (in my quick testing)
lynx and IE are the only two browsers that have issues with this
particular bit of code. Links, konqueror, safari, firefox, mozilla, etc
all seem to handle the pages without issue.
No. You also missed that links, elinks, and the emacs one (w3m or the
like) were also reported to fail. And sometimes lynx even works.
A more detailed set of tests (cache file included as attachment for
those curious, also the cache file was set as read only after it was
generated by epiphany so it was not regenerated during testing):
- epiphany v.2.16.3 - passed
- elinks v.0.11.1-5.1 - passed
- elinks v.0.4.2 - failed
- lynx v.2.8.5rel.1 - failed
- lynx v.2.8.5dev.7 - failed
- konqueror v.3.5.6-0.3.fc6 - passed
- konqueror v.3.1-13 Red Hat - passed
- I.E. v.6.0.3790.1830 (2k3) - passed
- I.E. v.6.0.2900.2180.xpsp_sp2_gdr.070227-2254 - failed
- w3m v.0.5.1 - failed
- w3m v.0.3.2.2 - failed
- firefox v.1.5.0.10 - passed
- Seamonkey v.1.8.1.2pre - passed
- Mozilla v.1.7.13 - passed
- Mozilla v.1.4.2 - passed
- safari v.1.0.3 - 50/50 - loads but doesn't render anything after
description link (viewing source shows missing content)
Thats everything I have immediate access to (installed and up and
running) - if we need more data points I can start installing older
versions of netscape and even backtrack through several version of IE
(win95,win98,winME,win2k) but my guess is that most of the gecko based
platforms that are even remotely recent are fine, same goes for
konqueror. I.E. is horked on XP until I.E. 7, win2k3 has a fix for this
already. eLinks seems to be handling it with something relatively
recent. And more or less everything else isn't handling the mime type.
quoted
Taking a quick glance at the code it seems IE claims to be xhtml+xml
compliant but apparently isn't really (any real surprise?) and lynx
just doesn't seem to support that mime type.
Lynx and many others. It is just a question of luch whether the served
page is acceptable or not.
Well the only difference in the pages being served is the mime type
application/html vs. application/xhtml+xml. Does anyone know the
original impetus to using application/xhtml+xml (despite the fact that
it's technically the correct choice) vs. just using application/html for
everything? I'm sure there was a good reason behind it and I'd rather
know what that reason was before I got changing things
quoted
The simplest fix would be to eliminate the distinction between
applicatoin/xhtml+xml and application/html in the gitweb code (or at
least in the caching gitweb code) and have everything claim a mimetype
of application/html and let the browser sort out if it's using xhtml or
html from the doctype. This would solve both the problem your seeing on
lynx and would make the caching gitweb usable by more IE users.
Great.
I'm going to wait for further comment, if I don't see anything by the
end of Monday (PDT) I'll go ahead and make the change and get it out to
kernel.org.
- John
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:43:06
J.H. wrote:
Well the only difference in the pages being served is the mime type
application/html vs. application/xhtml+xml. Does anyone know the
original impetus to using application/xhtml+xml (despite the fact that
it's technically the correct choice) vs. just using application/html for
everything? I'm sure there was a good reason behind it and I'd rather
know what that reason was before I got changing things
Presumably the motivation is so you know ahead of time that you can
invoke an XML parser rather than an SGML/HTML parser.
Note: http://www.w3.org/TR/xhtml-media-types/ states that text/html is
considered acceptable for HTML-compatible XHTML 1.0 but no other version
of XHTML 1.0. One of the main issues with making XHTML 1.0-compatible
is to make sure there is a space before the final / in the last
singleton: <foo /> rather than <foo/>
-hpa
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2016-06-15 22:43:06
H. Peter Anvin wrote:
Presumably the motivation is so you know ahead of time that you can
invoke an XML parser rather than an SGML/HTML parser.
Note: http://www.w3.org/TR/xhtml-media-types/ states that text/html is
considered acceptable for HTML-compatible XHTML 1.0 but no other version
of XHTML 1.0. One of the main issues with making XHTML 1.0-compatible
is to make sure there is a space before the final / in the last
singleton: <foo /> rather than <foo/>
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:06
J.H. wrote:
Well the only difference in the pages being served is the mime type
application/html vs. application/xhtml+xml. Does anyone know the
original impetus to using application/xhtml+xml (despite the fact that
it's technically the correct choice) vs. just using application/html for
everything? I'm sure there was a good reason behind it and I'd rather
know what that reason was before I got changing things
The idea was to serve application/xhtml+xml to browsers which _explicitely_
support it. But coupled with the fact that gitweb on kernel.org is modified
gitweb with caching, and it looks like it caches also HTTP headers...
I think simplest solution would be to remove complication, and always serve
text/html (at least for kernel.org gitweb with caching modifications).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
On Tue, 2007-04-24 at 03:06 +0200, Jakub Narebski wrote:
J.H. wrote:
quoted
Well the only difference in the pages being served is the mime type
application/html vs. application/xhtml+xml. Does anyone know the
original impetus to using application/xhtml+xml (despite the fact that
it's technically the correct choice) vs. just using application/html for
everything? I'm sure there was a good reason behind it and I'd rather
know what that reason was before I got changing things
The idea was to serve application/xhtml+xml to browsers which _explicitely_
support it. But coupled with the fact that gitweb on kernel.org is modified
gitweb with caching, and it looks like it caches also HTTP headers...
I think simplest solution would be to remove complication, and always serve
text/html (at least for kernel.org gitweb with caching modifications).
It's either that or store only the data not the headers and deal with
the headers on each request - but that might have other unintended
consequences I haven't thought of yet. Anyway I think your right -
short term solution if nothing else is serve out text/html and look more
closely at the problem when I rebase.
- John 'Warthog9' Hawley
From: Johan Herland <hidden> Date: 2016-06-15 22:43:06
On Tuesday 24 April 2007, H. Peter Anvin wrote:
H. Peter Anvin wrote:
quoted
Presumably the motivation is so you know ahead of time that you can
invoke an XML parser rather than an SGML/HTML parser.
Note: http://www.w3.org/TR/xhtml-media-types/ states that text/html
is considered acceptable for HTML-compatible XHTML 1.0 but no other
version of XHTML 1.0. One of the main issues with making XHTML
1.0-compatible is to make sure there is a space before the final /
in the last singleton: <foo /> rather than <foo/>
From: Johan Herland <hidden> Date: 2016-06-15 22:43:06
On Monday 23 April 2007, J.H. wrote:
A more detailed set of tests (cache file included as attachment for
those curious, also the cache file was set as read only after it was
generated by epiphany so it was not regenerated during testing):
- epiphany v.2.16.3 - passed
- elinks v.0.11.1-5.1 - passed
- elinks v.0.4.2 - failed
- lynx v.2.8.5rel.1 - failed
- lynx v.2.8.5dev.7 - failed
- konqueror v.3.5.6-0.3.fc6 - passed
- konqueror v.3.1-13 Red Hat - passed
- I.E. v.6.0.3790.1830 (2k3) - passed
- I.E. v.6.0.2900.2180.xpsp_sp2_gdr.070227-2254 - failed
- w3m v.0.5.1 - failed
- w3m v.0.3.2.2 - failed
- firefox v.1.5.0.10 - passed
- Seamonkey v.1.8.1.2pre - passed
- Mozilla v.1.7.13 - passed
- Mozilla v.1.4.2 - passed
- safari v.1.0.3 - 50/50 - loads but doesn't render anything after
description link (viewing source shows missing content)
Thats everything I have immediate access to (installed and up and
running) - if we need more data points I can start installing older
versions of netscape and even backtrack through several version of IE
(win95,win98,winME,win2k) but my guess is that most of the gecko
based platforms that are even remotely recent are fine, same goes for
konqueror. I.E. is horked on XP until I.E. 7, win2k3 has a fix for
this already. eLinks seems to be handling it with something
relatively recent. And more or less everything else isn't handling
the mime type.
From: Johan Herland <hidden> Date: 2016-06-15 22:43:06
On Tuesday 24 April 2007, J.H. wrote:
On Tue, 2007-04-24 at 03:06 +0200, Jakub Narebski wrote:
quoted
J.H. wrote:
quoted
Well the only difference in the pages being served is the mime
type application/html vs. application/xhtml+xml. Does anyone
know the original impetus to using application/xhtml+xml (despite
the fact that it's technically the correct choice) vs. just using
application/html for everything? I'm sure there was a good
reason behind it and I'd rather know what that reason was before
I got changing things
The idea was to serve application/xhtml+xml to browsers which
_explicitely_ support it. But coupled with the fact that gitweb on
kernel.org is modified gitweb with caching, and it looks like it
caches also HTTP headers... I think simplest solution would be to
remove complication, and always serve text/html (at least for
kernel.org gitweb with caching modifications).
It's either that or store only the data not the headers and deal with
the headers on each request - but that might have other unintended
consequences I haven't thought of yet. Anyway I think your right -
short term solution if nothing else is serve out text/html and look
more closely at the problem when I rebase.
Actually, if the caching mechanism supports the spec properly
(specifically RFC 2616, section 14.44), you should be able to work
around this, without disabling the cache:
You can return different responses to different clients as long as you
use the HTTP Vary header (RFC 2616, section 14.44) to indicate the
criteria for selecting which response to return.
Finally, you can use the client's HTTP Accept header to figure out
whether the browser supports XHTML or not. Basically just check
if "application/xhtml+xml" is listed with a greater (or equal, but
non-zero) Q-value than "text/html". I have a simple snippet of python
code that I use in my webapps for this purpose. It should be easily
translatable to the language of your choice. However, The list's spam
filter prevents me from attaching it here... :(
A similar solution using PHP is sketched out here:
http://keystonewebsites.com/articles/mime_type.php
Have fun!
...Johan
--
Johan Herland, [off-list ref]
www.herland.net
Ok the change is out and in the wild it will likely take about 24hrs to
work itself through everything. I'll check on it tomorrow to see how
things are going.
- John 'Warthog9' Hawley
On Sun, 2007-04-22 at 21:16 -0400, Nicolas Pitre wrote:
On Sun, 22 Apr 2007, J.H. wrote:
quoted
On Thu, 2007-04-19 at 23:02 -0400, Nicolas Pitre wrote:
quoted
Almost 2 months ago we discussed about gitweb not properly detecting the
client's ability to deal with application/xhtml+xml, something to do
with the caching of a previous request from a client which did support
it and serving the same content to a subsequent client which does not.
I apparently missed that entire conversation, my apologies.
quoted
Right now www.kernel.org/git is unusable for me with lynx as it keeps
prompting:
application/xhtml+xml D)ownload, or C)ancel
Is there any plan to have that fixed?
Well there are a couple of quick thoughts, so far (in my quick testing)
lynx and IE are the only two browsers that have issues with this
particular bit of code. Links, konqueror, safari, firefox, mozilla, etc
all seem to handle the pages without issue.
No. You also missed that links, elinks, and the emacs one (w3m or the
like) were also reported to fail. And sometimes lynx even works.
quoted
Taking a quick glance at the code it seems IE claims to be xhtml+xml
compliant but apparently isn't really (any real surprise?) and lynx
just doesn't seem to support that mime type.
Lynx and many others. It is just a question of luch whether the served
page is acceptable or not.
quoted
The simplest fix would be to eliminate the distinction between
applicatoin/xhtml+xml and application/html in the gitweb code (or at
least in the caching gitweb code) and have everything claim a mimetype
of application/html and let the browser sort out if it's using xhtml or
html from the doctype. This would solve both the problem your seeing on
lynx and would make the caching gitweb usable by more IE users.
Great.
Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html