I once read a page a few years ago about the various browsers' differing implementations of behaviour when a link with an empty href is clicked.
some of them linked to the directory (/path/to/file?query → /path/to/)
some of them linked to the exact same URI (/path/to/file?query → /path/to/file?query)
some of them linked to the same page (/path/to/file?query → /path/to/file)
...and various other behaviours.
Is the behaviour defined in a specification?
If so, what is the correct behaviour?
If so, have the latest versions of the big five browsers today fixed their implementations?
Since there's no "specification" for contents of HREF (at least in HTML 4), the browsers can do whatever they damn well please.
UPDATE However, aside from HTML, there's an RFC3986: Uniform Resource Identifier (URI): Generic Syntax. It has section 4.4. Same-Document Reference which says:
When a URI reference refers to a URI that is, aside from its fragment
component (if any), identical to the base URI (Section 5.1), that
reference is called a "same-document" reference. The most frequent
examples of same-document references are relative references that are empty ...
I do not necessarily read the above as "an empty URI MUST cause the client to reload the same socument's URI", but it does sound like a "best practice" type of wording; so if I was implementing my own browser I'd almost certainly follow such a behavior.
On a related note, here's a good recent 3/2010) roundup of how browsers treat empty src attribute of <img> tag: http://www.nczonline.net/blog/2010/03/16/empty-string-urls-in-html-a-followup/ and http://www.nczonline.net/blog/2010/07/13/empty-string-urls-browser-update/ . Please note that it is a big deal, since having and empty img src would cause the page to endlessly re-load itself in the worst case scenario.
Related
I'm trying to lock down my pages with a content security policy (CSP). The default CSP is too restrictive (and I cannot change the code to make it compliant, as it comes from a 3rd party), so I'm trying to define the minimal set of permissions in the CSP. To that end, I'd like to use style-src-attr and script-src-attr. And I'd like to use these with a nonce. I can see how to specify the nonce for both of these in the CSP. What I'm not sure about is how to specify the nonce for the html element (in the case of style-src-attr) and the javascript object (in the case of script-src-attr). I looked for an example, but couldn't find anything. Please give an example of how this could be done.
I stumbled over this question in actually preparing a lecture on the topic. The answer to the question is: you cannot.
Looking at the CSP Spec (https://www.w3.org/TR/CSP3/#match-element-to-source-list), only script or style tags can be nonced. The -attr variants do not apply to stand-alone elements (script tags, style tags, or links to CSS files), as per the spec (https://w3c.github.io/webappsec-csp/#directive-script-src-attr)
The script-src-attr directive applies to event handlers and, if present, it will override the script-src directive for relevant checks.
Bottom line, in the current specificiation, it should not be possible to allow event handlers through nonces. It is possible to rely on unsafe-hashes and put the hashes of known event handlers in there, but even that is not fully supported in browser (FF and Safari lack support, see https://caniuse.com/mdn-http_headers_csp_content-security-policy_unsafe-hashes)
I have several html pages with a lot of equations rendered by Mathjax. I would like to refer to several equations not especially in the same page.
The problem is that "\eqref" is only working if the equation is in the same page.
One solution would be to use "\tag{}" for all equations and use simple html links.
For example,
\label{myequation} \tag{4.1}
and the link would be
" 4.1 "
The problem with that solution is that I need to have personal tag for all equations.
Does anyone has a solution for referring to equations in different pages by producing tags automatically ?
See the documentation for automatic equation numbering. This allows you to have your equations numbered automatically rather than requiring \tag. Note that any numbered or tagged equation automatically gets an ID that can be used in a link, so there is no requirement to use \label (though it helps if you are adding and removing equations during editing). If an equation is numbered 5, then the id is mjx-eqn-5. There are functions that you can override in order to change the format of the equation numbers. See the equationNumbers section of the TeX configuration parameters documentation.
Edit: Now that I understand your request, I can tell you that to do what you ask for would require MathJax to know the label-to-tag mapping for the other pages in your site (not just the page currently being viewed). MathJax doesn't have that data available to it. The only way to do it would be to create data files for the other pages that includes that data so that MathJax could load it and have it available. While technically possible, it would be a bit cumbersome to do that, especially since JavaScript (normally) can't write files for you.
On the other hand, the only place the label-to-tag mapping is needed is for the text that acts as the link itself (that is, if eq:sum refers to equation 4.1, then you would want "4.1" to be the text that links to that equation. Note that the link itself will be to myotherpage#eq:sum, so the only thing that needs the number is the link text itself. If you were willing to use something like "[sum]" as the link text for eq:sum (e.g., "In equation [sum] we see..."), then you would not need the label-to-tag mapping, and \eqref could be modified to handle that. But if you really want the equation number as the link, you would need a lot more infrastructure to make that happen.
Does anyone have a link to a concise summary of what makes a portlet "JSR-286 compliant" vs being only "JSR-168 compliant". I've got a copy of the spec and that's anything but concise so linking the spec is not a useful answer. I've searched the web for an hour now and I've found nothing that is clear (aside from the spec, which of course requires that you read the previous spec too, and then weed out the "new features" from the "required compliance".
Particularly I've found that there's quite a bit of confusion out there on the necessity of web.xml, which appears to come from people using Liferay and not realizing that Liferay is dropping in a web.xml for them.
Do JSR-286 portlets require a web.xml file in their WAR files?
What I'd really like is something that contains one or more of the following lists:
Things you have to do to a JSR-168 to make it become JSR-286 compliant
Things you must not do, that would cause an otherwise JSR-286 compliant portlet to be considered only JSR-168.
You can leave "use the portlet-app_2_0.xsd" off the list, as I consider that part obvious.
I'm open to the answer that both lists are empty aside from the DTD/xsd for portlet.xml, and the difference is only in what the portal supports, but please back that assertion up with a link or other reference.
The reason I care is I see posts about Vaadin portlets in Liferay that imply that some features are not available for JSR-168 portlets... It may also be that some logic in Liferay switches based on which version of portlet.xml it sees, but I haven't confirmed that either so that would be interesting information too, but not the answer to my question.
According to this doc, but it's also mentioned in jsr286:
The JSR 286 spec(Portlet 2.0) does not break binary compatibility with JSR168(Portlet 1.0). This means that all portlets written against the Portlet 1.0 specification can run unchanged. The only exceptions to this rule are:
renderResponse.setContentType is no longer required before calling getWriter or getOutputstream. In JSR168, calling getWriter or getOutputstream without previously setting the content type resulted in an IllegalStateException.
getProtocol for included servlets / JSPs returns ‘HTTP/1.1’, In JSR168, it returned null.
So as long as your jsr168 portlet doesn't depend on the value returned by getProtocol() you're safe (ie every jsr168 portlet is a jsr286 portlet).
The posts you see seem to be logical as jsr286 is a newer spec and there are some features that make jsr268 portlet not a jsr168 portlet.
Ok, Since I've not found anything new that distinguishes a 2.0 portlet from a 1.0 portlet (aside from using additional services and ) I'll begin the lists for my answer here.
Must Do:
Conform to the 2.0 XSD for portlet.xml (xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd")
Must Not Do:
Rely on getWriter throwing an exception if renderResponse.setContentType has not been called yet. (Seems unlikely anyway)
Rely on getProtocol() returning null
The upshot is, if you simply convert your portlet.xml, you are now "286 compliant" unless you relied on the two items in the second list for your program flow. I can't find anything else, but if someone finds another item for these lists, please edit.
The good people of OWASP emphasize that you MUST use the escape syntax for the part of the HTML document you’re putting untrusted data into (body, attribute, JavaScript, CSS, or URL). See OWASP - XSS. Their API (developed by the ESAPI team) subsequently caters for this having encoders for each context:
ESAPI.encoder().encodeForHTML("input");
ESAPI.encoder().encodeForHTMLAttribute("input");
ESAPI.encoder().encodeForJavaScript("input");
ESAPI.encoder().encodeForCSS("input");
ESAPI.encoder().encodeForURL("input");
Subsequently this allows the developer to cater for DOM-based XSS .
So my question is how does GWT's safehtml package cater for this or does it merely focus on HTML encoding?
SafeHtmlTemplates will do it (client-side only though, as it relies on a GWT generator). It'll parse the HTML fragment using a "tag soup" parser, that will infer the context and either log a warning or throw if the argument cannot be used in this context (for instance, it prevents all use of placeholders in script context). This is still in flux though (SafeUri is still in review and SafeStyles is still severely limited) but it'll be there in due time (should be in GWT 2.4 I think).
Otherwise:
SafeHtmlUtils's will escape all of <, >, &, ' and " so the result is safe for "HTML" and "HTML attribute" contexts
SafeHtmlBuilder's various append methods will just call SafeHtmlUtils under the hood
UriUtils provides tools to scrub unsafe URIs (you'll still need a SafeHtmlUtils pass or equivalent afterwards if you're building an HTML string –vs. using the value directly for an image's source or anchor's href–).
SafeStyles doesn't provide anything specific in itself, but SafeHtmlTemplates will only allow it at the beginning of a CSS context, and will log a warning if you try to put anything else in a CSS context. SafeStylesBuilder is expected to be extended with type-safe methods, to help build well-formed CSS.
I've been working on a SafeUri interface, similar to SafeStyles but in a URL context. In due time, SafeHtmlTemplates will only allow a SafeUri or a String as the full value of a URL attribute, passing the String through UriUtils to make sure it's safe.
In brief, I think the answer to your question is: yes, GWT's safehtml package cater for this; but you'll probably have to always use the latest version of GWT (at least for the coming year) to be safe.
I'm eager to move towards a more standards-based, accessible and semanticly-correct web development approach. At the office, I don't expect there to be huge changes straight away, but I'm trying to start laying down some of the basic foundations for progress further down the track.
Part of this process is the introduction of the rel attribute in links and other such content. This extends further than the familiar old
<link href="mystyles.css" type="text/css" rel="stylesheet" />
which many developers would probably throw in without even thinking about it. I'm curious to know if anyone uses rel regularly in other ways. For example, setting your main navigation's link back to the home page with rel="start".
If you have implemented Link Relations in your own project, what prompted you to adopt them and what benefits were you trying to realise?
If you have looked at Link Relations but decided against their use, what was the basis for your decision?
I frequently use the rel (and rev) attributes with a wide range of values on both <link/> and <a/> elements.
I've outlined some of the more common (and more useful) relationship types below. A more complete list of rel values is maintained on the microformats wiki.
HTML 4
There are several standard link types defined by the HTML 4 specification.
alternate - Used when providing a link to an alternative version of an HTML document, for example in a different language or another format. This is most commonly used when linking to an syndicated (RSS or Atom) version of a web site.
next and previous - Used to indicate the next and previous documents in a series of documents. If rel="next" is used on a <link/> element then some browsers will pre-fetch the contents of the linked document (see the MDC link prefetching FAQ).
XFN
XFN (XHTML Friends Network) is a microformat used to describe the relationships between the people that are represented by web pages. It also allows a page to indicate other pages that represent the same person (e.g. my blog, my Twitter profile and my Stack Overflow profile all represent me). It does all of this by defining a set of rel values:
me - Used to indicate that the linking page and the linked page represent the same user. This is widely adopted by many social sites (including Stack Overflow) when linking from a user profile to the user's own web site.
contact, aquantance and friend - indicates that you know the person you are linking and how well you know them.
met - indicates that you have met the person you are linking to.
co-worker and colleague - indicate that you either work with or work in the same field as the person you are linking to.
co-resident and neighbor - indicate that you live with or near the person you are linking to.
child, parent, sibling, spouse and kin - indicate that you are linking to a member of your family.
muse, crush, date and sweetheart - indicate a romantic relationship with the person you are linking to.
These relationships can be parsed and used to determine information about a user, such as who their friends are or what other online profiles they possess. For more information on current, and potential future, applications of this the following pages might be of interest:
Ben Ward's article on Portable Social Networks.
The list of XFN implementations on the microformats wiki.
Other
There are various other link types defined by various specifications:
nofollow - Used to indicate that search engines should not follow a link when crawling a web page. See the rel-nofollow specification.
canonical - Used to indicate that another URL is the canonical version of the current page and should therefore be favoured by search engines. This is also used with the rev attribute to indicate an alternative, usually shorter, URL for the current page (i.e. rev="canonical" indicates that the current URL is the canonical version of the linked URL). More information and tools can be found in Simon Willison's blog entry on rev=canonical.
tag - Used to indicate that the linked page is a tag (i.e. keyword) describing the linking page. See the rel-tag specification.
license - Used to indicate the license under which the content of the linking page is released. See the rel-license specification.
I use the rel="nofollow" for user contributed links in blog comments. Google wont follow the link and it wont get a higher page rank because of the link.
One thing I've used them for is as a way to designate external links that should be opened in a new window. This functionality isn't possible with strict XHTML, because the target attribute is no longer allowed on <a> tags. But with some javascript and the rel attribute you can do a pretty decent job of it, as outlined in this article: New-Window Links in a Standards-Compliant World.
As Chad said, I use rel="external" to designate links I'd like to open in a new window (leveraging some jQuery to make it possible).
I also use rel="nofollow" when I'd like to make the bots that follow rules (like Google bot) not index my link.
It's useful on public websites to automatically add the nofollow, otherwise it could become enticing for spammers to make a link farm out of your blog comments, for example.