search

eclipse-ee4j / jersey

Eclipse Jersey Project - Read our Wiki:
https://github.com/eclipse-ee4j/jersey/wiki
Other
689 stars 351 forks source link

Ugliest Accept headerin the world ? #503

Closed jerseyrobot closed 15 years ago

jerseyrobot commented 15 years ago

Is this the ugliest Accept header in the world?

I am setting up a project that have cell phones involved and one Samsung send this thing as the Accept HTTP header:

Accept: text/vnd.wap.wml, text/css, text/ecmascript, image/png, image/gif, image/jpeg; q=0.5, image/x-bmp; q=0.3, image/vnd.wap.wbmp; q=0.2, audio/mid, audio/midi, audio/qcelp, audio/vnd.qcp, audio/vnd.qcelp, audio/aac, audio/mp3, audio/x-wav, audio/x-wave, audio/mpeg3, audio/mpeg, audio/mpg, audio/amr, application/x-pmd, application/x-cmx, application/x-pmd, audio/m4a, audio/mp4, audio/3gpp, audio/3gpp2, audio/mp4a-latm, video/3gpp, video/3gpp2, video/mp4, video/mp4v-es, text/vnd.sun.j2me.app-descriptor, text/x-pcs-gcd, multipart/mixed; q=.1, multipart/vnd.sprint-pre-cache, application/xhtml+xml; profile=http://www.wapforum.org/xhtml, application/vnd.wap.xhtml+xml, application/sdp, application/x-pcs-mcd+xml, text/plain, application/vnd.wap.wmlscriptc, application/vnd.wap.wmlc application/vnd.wap.sic, application/vnd.wap.slc, application/sia, application/vnd.wap.mms-message

I received HTTP status 400 with content: The HTTP header field "accept" with value ... could not be parsed.

While supporting almost every format in the world, it does so by violating some rules in the HTTP rfc:

Violation 1: (Need quotes) application/xhtml+xml; profile=http://www.wapforum.org/xhtml,

Violation 2: (Space to separate two mimes) application/vnd.wap.wmlc application/vnd.wap.sic,

While I could be pissed all day long about this phone, I have to support it and I even wrote a small patch. (Accept / when you don't know how to write an Accept header)

Whould there be a way to set a relaxed Accept header parsing for a specific server ?

Have a nice day !

Environment

Operating System: All Platform: All

jerseyrobot commented 6 years ago
jerseyrobot commented 15 years ago

@glassfishrobot Commented Reported by poitrae@java.net

jerseyrobot commented 15 years ago

@glassfishrobot Commented sandoz@java.net said: That is indeed a very very ugly header.

I think they best way to approach this is to develop a ContainerRequestFilter [1] to "normalize" the request header as you require.

There are facilities to parse HTTP header content that may help, have a look at the packages:

https://jersey.dev.java.net/source/browse/checkout/jersey/tags/jersey-1.0.2/api/jersey/com/sun/jersey/core/header/package-summary.html

https://jersey.dev.java.net/source/browse/checkout/jersey/tags/jersey-1.0.2/api/jersey/com/sun/jersey/core/header/reader/package-summary.html

but you might need to write a special tokenizer given that abusive header.

I am on holiday next week, 2nd to 6th March, and do not have time to get into further details now.

[1] https://jersey.dev.java.net/source/browse/checkout/jersey/tags/jersey-1.0.2/api/jersey/com/sun/jersey/spi/container/ContainerRequestFilter.html

jerseyrobot commented 15 years ago

@glassfishrobot Commented sandoz@java.net said: I would prefer not to maintain and support anything specific for such non-conforming clients. Instead Jersey provides a mechanism, via filters, to plug in support.

Also Jersey providers an HTTP header tokenizer that could be used to develop a parser for such a grotesque header. See com.sun.jersey.core.header.reader.HttpHeaderReader in the jersey-core module.

jerseyrobot commented 15 years ago

@glassfishrobot Commented Was assigned to jersey-issues

jerseyrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JERSEY-231

jerseyrobot commented 15 years ago

@glassfishrobot Commented Marked as won't fix on Wednesday, March 11th 2009, 10:50:04 pm