JDK-8117901 : oracle.com menu issues
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-09-04
  • Updated: 2015-06-17
  • Resolved: 2012-10-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Relates :  
JDK-8089812 - Image::drawImage() ignores CompositeOperator
Description
http://www.oracle.com/index.html
Menus (Products and Services, Solutions etc) do not open when hovered. They also lack gradient that appears in other browsers.
Comments
Setting the Content-Length attribute for HttpURLConnection is not allowed, at least as of 1.7/1.8. It is considered as a "restricted header" and will be ignored. For this to work the property "sun.net.http.allowRestrictedHeaders" must be set to true. See https://javafx-jira.kenai.com/browse/RT-35868
15-05-2015
Looks good. I think I'd prefer 'isSimpleRequest' to be named something like 'isGetOrHead' as the latter is more concise and more specific, but that would only be my personal preference.
29-10-2012
http://javaweb.us.oracle.com/jcg/fx-webrevs/RT-24709/3
29-10-2012
Looks good to me. I'm for isGetOrHead too.
29-10-2012
Well, if the GET or any other request has a message body, the content length will be set by the "if (sendFormData)" branch, as required by the spec you are citing. The problem is in the alternative case where formDataElements == null i.e. we don't have any data to send. I don't think we should be setting Content-Length to 0 in all such cases, especially on GET and HEAD requests. Major browsers do not do so. For now, I'd either blacklist GET and HEAD here or whitelist POST and PUT.
26-10-2012
http://javaweb.us.oracle.com/jcg/fx-webrevs/RT-24709/2 Note, that the HTTP 1.1 does not prohibit a message body even for the GET method. So I decided to include the Content-Length property with zero value for all methods when the output stream is not used. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13 http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length.
25-10-2012
What about other HTTP methods, like PUT? The problem here is, so far we have been fully relying on 'formDataElements' to determine whether we need to send any data (and, hence, set Content-Length), no matter what the request method is. Now it looks like that scheme is not 100% correct, and we need to start taking the method name into account. That is unfortunate because the set of request methods is not fixed in stone, that is, new methods can and actually do appear as the web evolves. It looks like we have no choice other than looking at the method name, but we need to be careful about which methods should trigger Content-Length <= 0. And a nit: the "else if" part should go on the same line as the preceding closing curly brace, see http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html#449
23-10-2012
http://javaweb.us.oracle.com/jcg/fx-webrevs/RT-24709/1/ Seems that for the POST method without body the Content-Length should be set manually. http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
23-10-2012