In draft-gregorio-atompub-multipart-04.txt chapter 3, third paragraph it says :
A multipart/related POST to a Media Collection MUST be a valid
multipart/related representation as defined by [RFC2387] and MUST
contain two body parts. One, referred to as the Entry Part, MUST be
an Atom Entry with a media type of 'application/atom+xml' or
'application/atom+xml;type=entry'. The other, referred to as the
Media Part, MUST be of a media type acceptable to the collection.
The object root MUST be the Entry Part. The Entry Part's atom:
content element MUST have a 'src' attribute whose value is the URI of
the related media in the Media Part. The 'src' attribute value MUST
be a 'cid:' URI as defined by [RFC2392]. The Content-Type: header of
the POST request MUST specify "application/atom+xml;type=entry" or
"application/atom+xml".
The question is, what does "MUST containt two body parts" mean? Does it mean that it must contain at least one Media Part, or that it must contain one, and only one, Media Part?
It means it must contain one Media Part and one Entry Part making two body parts in total.
Related
I'm receiving this error from the 508 compliance
The 'id' "authorizationsFiltersMember" specified for the WAI-ARIA property 'aria-labelledby' value is not valid
I've tried with authorizations filters member authorizations_filters_member and none of these works ?
How should I call it ?
All it is telling you is that you have either:
self referenced (i.e. <p id="authorizationsFiltersMember" aria-labelledby="authorizationsFiltersMember">) for example. Something can't be labelled by itself.
or that you have a typo in the element you are referencing (or you don't have an element with that ID at all).
or that the element you are referencing cannot be used as a label (i.e. if you gave it or it has a role that is an interactive element etc.)
Most likely is that you have a typo in the ID so try copy and pasting it again (ensure there are no spaces before and after it), it is a perfectly valid ID in terms of length and format.
As a side note: "authorizations filters member" would actually try and reference 3 elements with the IDs "authorizations", "filters" and "member" and combine them in that order to create the label for the element.
How can you ensure that the Boundary String in a Multipart MIME does not appear accidentally in the content itself and marks an incorrect border there?
Per the definition of MultiPart Content type https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
"... The encapsulation boundary MUST NOT appear inside any of the encapsulated parts. Thus, it is crucial that the composing agent be able to choose and specify the unique boundary that will separate the parts."
So is the task/burden of the agent creating the content to insure that the random string doesn't coincidentally occur inside. If it does find it, then a unique delimiter must generated until it passes muster.
According to RFC3986 (URI),
The query component is indicated by the first question
mark ("?") character and terminated by a number sign ("#") character
or by the end of the URI.
And specifies what characters are allowed inside. That's generic URI.
In daily interaction with various HTTP/Web servers, in URI http scheme, we're seeing query components represented as key=value pairs separated by & sign. RFC7230 (HTTP/1.1) says nothing about it, just that the content of the query component corresponds to RFC3986 generic definition.
The only standard defining said key-value pairs is HTML 4.01 while talking about content type application/x-www-form-urlencoded. It's also the only standard saying + should be treated as Space character in the query component.
However, as far as I could dig up in the specs, Content-Type header only applies to the message body, not its URI. And when, as an experiment, I'm googling for "asd zxc" Chrome sends the request /search?q=zxc+asd to Google without specifying said application/x-www-form-urlencoded content type at all.
Is it just conventional or am I missing something?
In the documentation for jsonapi for pagination is says the following:
For example, a page-based strategy might use query parameters such as
page[number] and page[size]
How would I represent this in the query string? http://localhost:4200/people?page[number]=1&page[size]=25, I don't think using a map link structure is a valid query string. Only the page parameter is reserved according to the documentation.
I don't think using a map link structure is a valid query string.
You're right technically, and that's why the spec has the note that says:
Note: The example query parameters above use unencoded [ and ] characters simply for readability. In practice, these characters must be percent-encoded, per the requirements in RFC 3986.
So, page[size] is really page%5Bsize%5D which is a valid query parameter name.
Only the page parameter is reserved according to the documentation.
When the spec text says that only page is reserved, it actually means that any page[......] style query parameter is reserved. (I can tell you that for sure as one of the spec's editors.) But it should say so more explicitly, so I'll open an issue for it.
I know absolute path-only URLs (/path/to/resource) are valid, and refer to the same scheme, host, port, etc. as the current resource. Is the URL still valid if the same (or a different!) scheme is added? (http:/path/to/resource or https:/path/to/resource)
If it is valid according to the letter of the spec, how well do browsers handle it? How well do developers that may come across the code in the future handle it?
Addendum:
Here's a simple test case I set up on an Apache server:
resource/number/one/index.html:
link
resource/number/two/index.html:
two
Testing in Chrome 43 on OS X: The URL displayed when hovering over the link looks correct. Clicking the link works as expected. Looking at the DOM in the web inspector, hovering over the a href URL displays an incorrect location (/resource/number/one/http:/resource/number/two/).
Firefox 38 appears to also handle the click correctly. Weird.
No, it’s not valid. From RFC 3986:
4.2. Relative Reference
A relative reference takes advantage of the hierarchical syntax
(Section 1.2.3) to express a URI reference relative to the name space
of another hierarchical URI.
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
The URI referred to by a relative reference, also known as the target
URI, is obtained by applying the reference resolution algorithm of
Section 5.
A relative reference that begins with two slash characters is termed
a network-path reference; such references are rarely used. A
relative reference that begins with a single slash character is
termed an absolute-path reference. A relative reference that does
not begin with a slash character is termed a relative-path reference.
A path segment that contains a colon character (e.g., "this:that")
cannot be used as the first segment of a relative-path reference, as
it would be mistaken for a scheme name. Such a segment must be
preceded by a dot-segment (e.g., "./this:that") to make a relative-
path reference.
where path-noscheme is specifically a path that doesn’t start with / whose first segment does not contain a colon, which addresses your question pretty specifically.