18 2002-10-25 02:33:21 +0000 For conneg, allow choosing the Accept-* headers to send. 2008-06-15 16:20:05 +0000 1 1 1 Unclassified Validator check 0.6.0b1 All All RESOLVED FIXED P2 enhancement 1.0 1 link ot dean elimerl john sierkb stian+w3c victor.engmark www-validator-cvs oldest_to_newest 20 0 link 2002-10-25 02:33:21 +0000 Reported by Christoph Päper: For the matter of content negotiation it would be nice if one could choose in <http://validator.w3.org:8001/detailed.html> the Accept (text/html vs. application/xhtml+xml), Accept-Language and perhaps Accept-Encoding HTTP headers sent by the validator. 45 1 link 2002-10-25 21:20:35 +0000 Comments from Björn Höhrmann: Since the user is likely trying to validate the document he would get, the Validator could just tunnel the received Accept headers to the remote host (don't forget to make sure the Accept:-line contains all types supported by the validator and the Accept-Langage header contains a * to ensure the user won't get a 406 response). Otherwise it would get rather complicated to implement a form that allows for complex choices in this regard. Just consider a resources beeing served as a dozen different types (e.g., RSS, HTML, SVG 1.0, SVG 1.1, XHTML Basic 1.0, XHTML 1.0 Strict, XHTML 1.1, some custom XHTML types, etc.) 686 2 orions 2003-08-07 14:59:00 +0000 Although the tunneling feature suggested by Björn would be handy, I'd be more interested in being able to supply exact values for the Accept-* headers. This way I can validate my WML, XHTML Mobile Profile, and CHTML output from my browser. 1996 3 bjoern 2004-06-02 14:28:01 +0000 *** Bug 784 has been marked as a duplicate of this bug. *** 2215 4 link 2004-09-01 16:47:10 +0000 Retarget 1.0. I don't think this will make it for 0.7. 5636 5 gideon 2005-09-01 02:41:32 +0000 A workaround for IE not handling application/xhtml+xml is to only send this MIME type when the UA offers to accept it, otherwise text/html is sent. This means that Mozilla browsers will be sent valid XHTML. However, the Validator will fault, because it doesn't send the relevant Accept header, and is therefore served the IE workaround. 9895 6 thedevek 2006-05-25 21:40:49 +0000 Ok.. considering this is a 3 1/2 year old bug.. When trying to use XHTML you will run into problems serving the correct MIME type to Internet Exploder users. There is a wonderful article at http://keystonewebsites.com/articles/mime_type.php that shows gets you started in the direction of correctly serving your documents as XHTML and HTML4. Unfortuantly, by doing that you are unable to validate your XHTML pages as the validator is incapable of sending the accept headers. Since no one really seems to be in a rush to correct this I went ahead and did it myself.. it may break stuff and be improper but I don't really care. Go to http://validator.w3.org/docs/install.html and install validator-0.7.2. When that is up and running download http://glimpse.onlineok.com/validator-accept.tgz with that you can either apply the patch inside or just untar it in your root validator directory and it will overwrite the correct files. You can now ask for text/html pages or application/xhtml+xml pages. There was someone here earlier wanting to be able to ask for SMS type pages, it would be trivial to add support for different acception options by making changes to share/templates/en_US/popup_accept.tmpl and htdocs/accept-select.html You can see this work at http://glimpse.onlineok.com/w3c-validator/ but please go easy on that since it is my desktop at work :) W3C team can feel free to use my code, I don't care.. I just think this is kind of important and critical to be in the validator if you want people actually taking XHTML seriously. 9897 7 427 thedevek 2006-05-25 22:08:17 +0000 Created attachment 427 patch to add accept-headers 11313 8 ot 2006-08-30 02:40:45 +0000 (In reply to comment #7) > Created an attachment (id=427) [edit] > patch to add accept-headers Thank you Derek for this patch. I think it has a few problems, however, which are hinted in other comments, namely, that text/html and application/xhtml+xml aren't the only media types accepted by this validator. I suppose the alternative suggested by orion in comment #2, of a free-field for the various Accept-* Headers. Whether or not it would be worth the extra volume of options (albeit on the advanced interface) is still not entirely clear to me. 15026 9 victor.engmark 2007-05-07 14:06:26 +0000 Good stuff; I'm having trouble validating a page with embedded SVG. In relation to this, it would be useful to have the following choices of which "Accept-" headers will be sent: * None * Current browser's (as found in HTTP request; useful for checking whether any single browser will balk) * Text field(s) (useful to test e.g. language auto-detection) 16802 10 ot 2007-09-26 13:50:16 +0000 I am removing the blocker to Bug 785. IMHO, a default and an option are orthogonal. I would actually welcome a fix to Bug #785 as a much better solution, making this one moot. 16844 11 ot 2007-09-27 10:20:36 +0000 After sitting with a colleague on the issue for a while today, we concluded that: * it was interesting to provide users with a way to trigger format and language negotiation, by having the validator send custom Accept and Accept-Language headers. * that the need for custom headers was rare, since most follow the good practice to give a specific URI to each representation of a negotiated resource. rare, but real, and limited to a few "experts", who would probably be OK reading the documentation and adding the parameter to validation URIs themselves. As a result, I added the accept and accept-language parameters into the validator, and documented them in the user's manual. These headers are marked as experimental, but will be in the 0.8.2 release. There won't, for the time being, be any GUI for now, which is typically the case for very rare or experts-only options, such as output=n3, debug=1 etc. 16846 12 ot 2007-09-27 10:28:59 +0000 see http://lists.w3.org/Archives/Public/www-validator-cvs/2007Sep/0209.html and http://lists.w3.org/Archives/Public/www-validator-cvs/2007Sep/0207.html 16848 13 ot 2007-09-27 10:34:14 +0000 (In reply to comment #12) > see > http://lists.w3.org/Archives/Public/www-validator-cvs/2007Sep/0209.html > and > http://lists.w3.org/Archives/Public/www-validator-cvs/2007Sep/0207.html Patch tested and on its way for 0.8.2 release. 16853 14 dean 2007-09-28 06:07:40 +0000 (In reply to comment #11) > After sitting with a colleague on the issue for a while today, we concluded > that: > * it was interesting to provide users with a way to trigger format and language > negotiation, by having the validator send custom Accept and Accept-Language > headers. > > * that the need for custom headers was rare, since most follow the good > practice to give a specific URI to each representation of a negotiated > resource. rare, but real, and limited to a few "experts", who would probably...... Giving a specific URI for separate HTML and XHTML pages is not a good practise at all and has been clearly pointed out before. One would run into various problems such as Internet Explorer users browsing to XHTML pages. Having duplicate content issues would also arise and give problems with Search engines and usability. Not to mention the added hassles of maintaining two files. Why is this such a big deal to fix? Does the W3C not want to encourage people to use XHTML with the correct mime type? Other validators send ACCEPT headers, why can't the W3C_validator? Thanks Dean 16854 15 dean 2007-09-28 06:20:47 +0000 (In reply to comment #11) > * that the need for custom headers was rare, since most follow the good > practice to give a specific URI to each representation of a negotiated > resource.... Really? the experts that I know of that actually *know how* to use XHTML in the real world do no such thing. Even the W3c's home page uses content negotiation based on the user-agents capability's and uses the same URL for XHTML(application/xhtml+xml) and HTML(text/html). Unfortunately (due to this bug #18) it validates with the (text/html) mime type and not the (application/xhtml+xml) that the home page sends my browser. Dean 16855 16 ot 2007-09-28 07:00:33 +0000 (In reply to comment #15) > (In reply to comment #11) > > > * that the need for custom headers was rare, since most follow the good > > practice to give a specific URI to each representation of a negotiated > > resource.... > Really? the experts that I know of that actually *know how* to use XHTML in the > real world do no such thing. Dean, there is more to content-negotiation than the hack for IE and XHTML. :) thanks olivier 16856 17 dean 2007-09-28 09:11:18 +0000 > Dean, there is more to content-negotiation than the hack for IE and XHTML. :) > > thanks > olivier > The only 'hack' in my content negotiation script is the line where I have to unnecessarily check for your user-agent as it fails to give my server an accept header. if (stristr($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml") || /* the line below is an unnecessary hack :) */ stristr($_SERVER["HTTP_USER_AGENT"], "W3C_Validator")) { $mime = "application/xhtml+xml"; } else { $mime = "text/html"; } header("Content-Type: $mime; charset=utf-8"); Thanks Dean 18217 18 stian+w3c 2008-01-06 18:11:54 +0000 It seems to me the W3C is promoting a double standard here, ignoring HTTP while demanding strict compliance with HTML/XHTML. My pages, which are written in XHTML 1.1, now do the following: If the HTTP_ACCEPT header indicates acceptance of application/xhtml+xml, I serve the page as XHTML 1.1. If the HTTP_ACCEPT header indicates acceptance of text/html (but not application/xhtml+xml), I deliberately choose to violate spec by serving it as text/html. This is a workaround to allow the content to be displayed by broken browsers; however, I make users very aware of this by printing a warning that their user agent does not support XHTML and some content may not render properly. If the HTTP_ACCEPT header contains neither of these, I return a 406 HTTP error. This seems the correct thing to do, since these user agents are demanding content in a form that my web server is unable to offer. In fact, although I'd have to go read the HTTP spec to confirm, it seems to me that by sending a blank (but present) HTTP_ACCEPT header, the W3C validator is stating that it will not accept *any* content, regardless of format. Yes, the root cause here is IE (and lynx, and a few older browsers, but primarily IE) not support XHTML. Yes, I've complained to Microsoft. Microsoft states that they'd rather not support it at all than add half-ass support by treating XHTML as tag soup. While I commend them for THAT, I fail to understand why a company with Microsoft's resources can't come up with an XHTML parser in the span of half a decade. But the fact that IE lacks support for XHTML is no excuse for the W3C to fail to validate my valid XHTML. The fact that I choose to serve SOME content to browsers such as IE *with* a warning should be irrelevant to the W3C, since the W3C validator is supposed to validate XHTML and therefore has no excuse to lie to the browser about supporting it in the first place. I guess people attempting to validate my sites will have to live with the 406 for now. This is the best way I can see to comply with HTTP content negotiation rules without adding a special case for the W3C; adding exceptional handling for a standards body is something I refuse to do. 18220 19 ot 2008-01-06 22:12:20 +0000 (In reply to comment #18) > If the HTTP_ACCEPT header indicates acceptance of text/html (but not > application/xhtml+xml), I deliberately choose to violate spec by serving it as > text/html. That's your choice. did you really need XHTML 1.1? > This is a workaround to allow the content to be displayed by broken > browsers; however, I make users very aware of this by printing a warning that > their user agent does not support XHTML and some content may not render > properly. Interesting method. I don't know if all the people visiting your site really need to know about such technicalities, but at least you're trying to raise awareness. > In fact, although I'd > have to go read the HTTP spec to confirm, it seems to me that by sending a > blank (but present) HTTP_ACCEPT header, the W3C validator is stating that it > will not accept *any* content, regardless of format. “If no Accept header field is present, then it is assumed that the client accepts all media types.” http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html > But the fact that IE lacks support for XHTML is no excuse for the W3C to fail > to validate my valid XHTML. Please see http://validator.w3.org/docs/users.html#option-accept 18225 20 link 2008-01-07 06:00:04 +0000 [ Hei Stian, forresten :-) ] (In reply to comment #18) > It seems to me the W3C is promoting a double standard here, ignoring HTTP while > demanding strict compliance with HTML/XHTML. The Validator has always strived to implement the standards as closely as possible, and has on occasion preferred to follow the HTTP spec rather then a W3C issued Recommendation when the two have been in seeming conflict. > […] it seems to me that by sending a blank (but present) HTTP_ACCEPT header, the > W3C validator is stating that it will not accept *any* content, regardless of format. If you can cite an authoritative argument based on RFC2616 that indicates the current Validator behavior is incorrect then that will be a quite weighty factor in determining how to deal with this issue. As far as we've been aware so far, the issue in this bug is one of practical implementations for publishers attempting to both use application/xhtml+xml _and_ cater to users of UAs that do not support it; apart from the general desirability of exposing generic content negotiation features to the Validator's users. We are not aware that the Validator's behaviour in this area is in violation of any standard (see e.g. the RFC2616 cite in Olivier's response in Comment #19). If your reading of the spec indicates otherwise then please do open a new bug detailing the issue! 427 2006-05-25 22:08:17 +0000 2006-05-25 22:08:17 +0000 patch to add accept-headers validator.diff text/plain 4935 thedevek ZGlmZiAtdXJOIC4uL3ZhbGlkYXRvcjIvY2dpLWJpbi9jaGVjayAuL2NnaS1iaW4vY2hlY2sKLS0t IC4uL3ZhbGlkYXRvcjIvY2dpLWJpbi9jaGVjawlTYXQgRmViIDE4IDE0OjA2OjQxIDIwMDYKKysr IC4vY2dpLWJpbi9jaGVjawlUaHUgTWF5IDI1IDE2OjExOjU3IDIwMDYKQEAgLTk4OSw2ICs5ODks MTEgQEAKICAgbXkgJHVhID0gbmV3IFczQzo6VmFsaWRhdG9yOjpVc2VyQWdlbnQgKCRDRkcsICRG aWxlKTsKICAgJHVhLT5lbnZfcHJveHkoKTsKICAgJHVhLT5hZ2VudCgiVzNDX1ZhbGlkYXRvci8k VkVSU0lPTiIpOworICBpZiAoKCRxLT5wYXJhbSgnYWNjZXB0JykgbmUgIm5vbmUiKSAmJiAkcS0+ cGFyYW0oJ2FjY2VwdCcpKQorICB7CisgICAgICR1YS0+ZGVmYXVsdF9oZWFkZXJzLT5wdXNoX2hl YWRlcignQWNjZXB0JyA9PiAkcS0+cGFyYW0oJ2FjY2VwdCcpKTsKKyAgICAgJFQtPnBhcmFtKCJh Y2NlcHQgIiAuICRxLT5wYXJhbSgnYWNjZXB0JykgPT4gVFJVRSApOworICB9CiAgICR1YS0+cGFy c2VfaGVhZCgwKTsgICMgRG9uJ3QgcGFyc2UgdGhlIGh0dHAtZXF1aXYgc3R1ZmYuCiAKICAgJHVh LT5wcm90b2NvbHNfYWxsb3dlZCgkQ0ZHLT57UHJvdG9jb2xzfS0+e0FsbG93fSB8fCBbJ2h0dHAn LCAnaHR0cHMnXSk7CmRpZmYgLXVyTiAuLi92YWxpZGF0b3IyL2h0ZG9jcy9hY2NlcHQtc2VsZWN0 Lmh0bWwgLi9odGRvY3MvYWNjZXB0LXNlbGVjdC5odG1sCi0tLSAuLi92YWxpZGF0b3IyL2h0ZG9j cy9hY2NlcHQtc2VsZWN0Lmh0bWwJV2VkIERlYyAzMSAxODowMDowMCAxOTY5CisrKyAuL2h0ZG9j cy9hY2NlcHQtc2VsZWN0Lmh0bWwJV2VkIE1heSAyNCAxNDozNTo1MiAyMDA2CkBAIC0wLDAgKzEs NSBAQAorPHNlbGVjdCBpZD0iYWNjZXB0IiBuYW1lPSJhY2NlcHQiPgorICA8b3B0aW9uIHZhbHVl PSJub25lIiBzZWxlY3RlZD0ic2VsZWN0ZWQiPihub25lIHNwZWNpZmllZCk8L29wdGlvbj4KKyAg PG9wdGlvbiB2YWx1ZT0idGV4dC9odG1sIj50ZXh0L2h0bWw8L29wdGlvbj4KKyAgPG9wdGlvbiB2 YWx1ZT0iYXBwbGljYXRpb24veGh0bWwreG1sIj5hcHBsaWNhdGlvbi94aHRtbCt4bWw8L29wdGlv bj4gCis8L3NlbGVjdD4KZGlmZiAtdXJOIC4uL3ZhbGlkYXRvcjIvaHRkb2NzL2RldGFpbGVkLWZv cm0uaHRtbCAuL2h0ZG9jcy9kZXRhaWxlZC1mb3JtLmh0bWwKLS0tIC4uL3ZhbGlkYXRvcjIvaHRk b2NzL2RldGFpbGVkLWZvcm0uaHRtbAlUaHUgRmViIDE2IDAwOjQwOjQ3IDIwMDYKKysrIC4vaHRk b2NzL2RldGFpbGVkLWZvcm0uaHRtbAlXZWQgTWF5IDI0IDE0OjUyOjE5IDIwMDYKQEAgLTU0LDYg KzU0LDEzIEBACiAgICAgICAgICAgICA8dGQ+PGxhYmVsIGZvcj0iZmJkIj48aW5wdXQgaWQ9ImZi ZCIgbmFtZT0iZmJkIiB0eXBlPSJjaGVja2JveCIgdmFsdWU9IjEiIC8+IFVzZSBGYWxsYmFjayBp bnN0ZWFkIG9mIE92ZXJyaWRlPC9sYWJlbD48L3RkPgogICAgICAgICAgIDwvdHI+CiAgICAgICAg ICAgPHRyPgorICAgICAgICAgICAgPHRoPjxsYWJlbCBmb3I9ImFjY2VwdCI+QWNjZXB0OjwvbGFi ZWw+PC90aD4KKyAgICAgICAgICAgIDx0ZD4KKzwhLS0jaW5jbHVkZSB2aXJ0dWFsPSJhY2NlcHQt c2VsZWN0Lmh0bWwiIC0tPgorICAgICAgICAgICAgPC90ZD4KKyAgICAgICAgICAgIDx0ZD48bGFi ZWwgZm9yPSJmYmEiPjxpbnB1dCBpZD0iZmJhIiBuYW1lPSJmYmEiIHR5cGU9ImNoZWNrYm94IiB2 YWx1ZT0iMSIgLz4gVXNlIEZhbGxiYWNrIGlzbnRlZGEgb2YgT3ZlcnJpZGUoPyk8L2xhYmVsPjwv dGQ+CisgICAgICAgICAgPC90cj4KKyAgICAgICAgICA8dHI+CiAgICAgICAgICAgICA8dGggcm93 c3Bhbj0iNCI+T3B0aW9ucyAoPGEgdGl0bGU9IkV4cGxhbmF0aW9uIGZvciB0aGVzZSBvcHRpb25z IiBocmVmPSJkb2NzL3VzZXJzLmh0bWwjT3B0aW9ucyI+SGVscDwvYT4pOjwvdGg+CiAgICAgICAg ICAgICA8dGQ+PGxhYmVsIGZvcj0ic3MiPjxpbnB1dCBpZD0ic3MiIG5hbWU9InNzIiB0eXBlPSJj aGVja2JveCIgdmFsdWU9IjEiIC8+IFNob3cgU291cmNlPC9sYWJlbD48L3RkPgogICAgICAgICAg ICAgPHRkPjxsYWJlbCBmb3I9Im91dGxpbmUiPjxpbnB1dCBpZD0ib3V0bGluZSIgbmFtZT0ib3V0 bGluZSIgdHlwZT0iY2hlY2tib3giIHZhbHVlPSIxIiAvPiBTaG93IE91dGxpbmU8L2xhYmVsPjwv dGQ+CmRpZmYgLXVyTiAuLi92YWxpZGF0b3IyL2h0ZG9jcy94bWwtcmVzdWx0cy5jc3MgLi9odGRv Y3MveG1sLXJlc3VsdHMuY3NzCi0tLSAuLi92YWxpZGF0b3IyL2h0ZG9jcy94bWwtcmVzdWx0cy5j c3MJTW9uIEZlYiAyNCAxNzozMzoxOCAyMDAzCisrKyAuL2h0ZG9jcy94bWwtcmVzdWx0cy5jc3MJ V2VkIE1heSAyNCAxNDoyNzozOSAyMDA2CkBAIC03LDcgKzcsNyBAQAogICAgJElkOiB4bWwtcmVz dWx0cy5jc3MsdiAxLjUgMjAwMy8wMi8yNCAyMzozMzoxOCB2aWxsZSBFeHAgJAogKi8KIAotcmVz dWx0LCBtZXRhLCB1cmksIG1vZGlmaWVkLCBzZXJ2ZXIsIHNpemUsIGVuY29kaW5nLCBkb2N0eXBl LCB3YXJuaW5ncywgbWVzc2FnZXMge2Rpc3BsYXk6IGJsb2NrfQorcmVzdWx0LCBtZXRhLCB1cmks IG1vZGlmaWVkLCBzZXJ2ZXIsIHNpemUsIGVuY29kaW5nLCBkb2N0eXBlLCBhY2NlcHQsIHdhcm5p bmdzLCBtZXNzYWdlcyB7ZGlzcGxheTogYmxvY2t9CiBzdHJvbmcsIGEge2Rpc3BsYXk6IGlubGlu ZX0KIAogbWV0YSB7CkBAIC0yMyw2ICsyMyw3IEBACiBzaXplICAgICB7dGV4dC1iZWZvcmU6ICdT aXplOiAnfQogZW5jb2Rpbmcge3RleHQtYmVmb3JlOiAnRW5jb2Rpbmc6ICd9CiBkb2N0eXBlICB7 dGV4dC1iZWZvcmU6ICdEb2N0eXBlOiAnfQorYWNjZXB0ICAge3RleHQtYmVmb3JlOiAnQWNjZXB0 OiAnfQogCiB3YXJuaW5ncyB7CiAgIGJvcmRlci10b3A6IDFweCBzb2xpZCByZWQ7CmRpZmYgLXVy TiAuLi92YWxpZGF0b3IyL2h0ZG9jcy94bWwtcmVzdWx0cy54c2wgLi9odGRvY3MveG1sLXJlc3Vs dHMueHNsCi0tLSAuLi92YWxpZGF0b3IyL2h0ZG9jcy94bWwtcmVzdWx0cy54c2wJV2VkIEp1bCAy MSAxMDowNjo1NSAyMDA0CisrKyAuL2h0ZG9jcy94bWwtcmVzdWx0cy54c2wJV2VkIE1heSAyNCAx NDoyNTo1OSAyMDA2CkBAIC0zMiw2ICszMiw3IEBACiAgICAgICA8dHI+PHRoIHNjb3BlPSJyb3ci PkNvbnRlbnQtTGVuZ3RoPC90aD4gPHRkPjx4c2w6dmFsdWUtb2Ygc2VsZWN0PSJzaXplIi8+PC90 ZD48L3RyPgogICAgICAgPHRyPjx0aCBzY29wZT0icm93Ij5FbmNvZGluZzwvdGg+ICAgICAgIDx0 ZD48eHNsOnZhbHVlLW9mIHNlbGVjdD0iZW5jb2RpbmciLz48L3RkPjwvdHI+CiAgICAgICA8dHI+ PHRoIHNjb3BlPSJyb3ciPkRvY3R5cGU8L3RoPiAgICAgICAgPHRkPjx4c2w6dmFsdWUtb2Ygc2Vs ZWN0PSJkb2N0eXBlIi8+PC90ZD48L3RyPgorICAgICAgPHRyPjx0aCBzY29wZT0icm93Ij5BY2Nl cHQ8L3RoPiAgICAgICAgIDx0ZD48eHNsOnZhbHVlLW9mIHNlbGVjdD0iYWNjZXB0Ii8+PC90ZD48 L3RyPgogICAgIDwvdGJvZHk+CiAgIDwvdGFibGU+CiAgIDwveHNsOnRlbXBsYXRlPgpkaWZmIC11 ck4gLi4vdmFsaWRhdG9yMi9zaGFyZS90ZW1wbGF0ZXMvZW5fVVMvcG9wdXBfYWNjZXB0LnRtcGwg Li9zaGFyZS90ZW1wbGF0ZXMvZW5fVVMvcG9wdXBfYWNjZXB0LnRtcGwKLS0tIC4uL3ZhbGlkYXRv cjIvc2hhcmUvdGVtcGxhdGVzL2VuX1VTL3BvcHVwX2FjY2VwdC50bXBsCVdlZCBEZWMgMzEgMTg6 MDA6MDAgMTk2OQorKysgLi9zaGFyZS90ZW1wbGF0ZXMvZW5fVVMvcG9wdXBfYWNjZXB0LnRtcGwJ VGh1IE1heSAyNSAxNjowNDoxOSAyMDA2CkBAIC0wLDAgKzEsNSBAQAorPHNlbGVjdCBpZD0iYWNj ZXB0IiBuYW1lPSJhY2NlcHQiPgorICA8b3B0aW9uIHZhbHVlPSJub25lIj4obm9uZSBzcGVjaWZp ZWQpPC9vcHRpb24+CisgIDxvcHRpb24gdmFsdWU9InRleHQvaHRtbCIgPFRNUExfSUYgTkFNRT0i YWNjZXB0IHRleHQvaHRtbCI+c2VsZWN0ZWQ9InNlbGVjdGVkIjwvVE1QTF9JRj4+dGV4dC9odG1s PC9vcHRpb24+CisgIDxvcHRpb24gdmFsdWU9ImFwcGxpY2F0aW9uL3hodG1sK3htbCIgPFRNUExf SUYgTkFNRT0iYWNjZXB0IGFwcGxpY2F0aW9uL3hodG1sK3htbCI+c2VsZWN0ZWQ9InNlbGVjdGVk IjwvVE1QTF9JRj4+YXBwbGljYXRpb24veGh0bWwreG1sPC9vcHRpb24+IAorPC9zZWxlY3Q+CmRp ZmYgLXVyTiAuLi92YWxpZGF0b3IyL3NoYXJlL3RlbXBsYXRlcy9lbl9VUy90YWJsZS50bXBsIC4v c2hhcmUvdGVtcGxhdGVzL2VuX1VTL3RhYmxlLnRtcGwKLS0tIC4uL3ZhbGlkYXRvcjIvc2hhcmUv dGVtcGxhdGVzL2VuX1VTL3RhYmxlLnRtcGwJU2F0IEZlYiAxMSAwNjozODo0NiAyMDA2CisrKyAu L3NoYXJlL3RlbXBsYXRlcy9lbl9VUy90YWJsZS50bXBsCVdlZCBNYXkgMjQgMTU6MTY6MDYgMjAw NgpAQCAtNTUsNiArNTUsMTQgQEAKICAgPFRNUExfRUxTRT4KICAgICA8dHI+PHRoPkRvY3R5cGU6 PC90aD48dGQgY29sc3Bhbj0iMiI+PFRNUExfSU5DTFVERSBOQU1FPSJwb3B1cF9kb2N0eXBlLnRt cGwiPjwvdGQ+PC90cj4KICAgPC9UTVBMX0lGPgorICA8VE1QTF9JRiBOQU1FPSJmaWxlX2FjY2Vw dCI+CisgICAgPHRyPgorICAgICAgPHRoPjxsYWJlbCBmb3I9ImFjY2VwdCIgdGl0bGU9IkFjY2Vw dCI+QWNjZXB0PC9sYWJlbD46PC90aD4KKyAgICAgIDx0ZD48VE1QTF9WQVIgTkFNRT0iZmlsZV9h Y2NlcHQiIEVTQ0FQRT0iSFRNTCI+PC90ZD48dGQ+PFRNUExfSU5DTFVERSBOQU1FPSJwb3B1cF9h Y2NlcHQudG1wbCI+PC90ZD4KKyAgICA8L3RyPgorICA8VE1QTF9FTFNFPgorICAgIDx0cj48dGg+ QWNjZXB0OjwvdGg+PHRkIGNvbHNwYW49IjIiPjxUTVBMX0lOQ0xVREUgTkFNRT0icG9wdXBfYWNj ZXB0LnRtcGwiPjwvdGQ+PC90cj4KKyAgPC9UTVBMX0lGPgogPC9UTVBMX0lGPgogPFRNUExfSUYg TkFNRT0iZmlsZV9uYW1lc3BhY2UiPgogICAgIDx0cj4K