Let's suppose I do ACL method on a resource for the first time:
<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:">
<D:ace>
<D:principal>
<D:href>http://www.example.com/users/esedlar</D:href>
</D:principal>
<D:grant>
<D:privilege><D:write/></D:privilege>
</D:grant>
</D:ace>
</D:acl>
And then on the same resource for a second time:
<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:">
<D:ace>
<D:principal>
<D:href>http://www.example.com/users/esedlar</D:href>
</D:principal>
<D:grant>
<D:privilege><D:read/></D:privilege>
</D:grant>
</D:ace>
</D:acl>
Should D:write be retained for http://www.example.com/users/esedlar after request #2?
RFC extract: https://www.rfc-editor.org/rfc/rfc3744#page-40
Specifically, the ACL
method only permits modification to ACEs that are not inherited, and
are not protected. An ACL method invocation modifies all non-
inherited and non-protected ACEs in a resource's access control list
to exactly match the ACEs contained within in the DAV:acl XML element
(specified in Section 5.5) of the request body. An ACL request body
MUST contain only one DAV:acl XML element. Unless the non-inherited
and non-protected ACEs of the DAV:acl property of the resource can be
updated to be exactly the value specified in the ACL request, the ACL
request MUST fail.
Related
I am trying to find where the XSD and the semantics for the deployment descriptor web.xm file is defined in the Servlet 3.0 specification.
Alternatively, where is an authoritative description of the various supported elements and attributes that can appear inside web.xml and what the default behavior of the container is, in case some elements / attributes are absent.
This started by me wondering what is the default value for the http-only and secure elements inside session-config, e.g. as in:
<session-config>
<session-timeout>60</session-timeout>
<cookie-config>
<http-only>true</http-only>
<secure>false</secure>
</cookie-config>
</session-config>
I am reasonably certain the default values are false for both but I wanted to see where this is authoritatively specified.
Looking at the Java Servlet 3.0 spec there is no XSD. There is a sample XML file (on pg. 169) which has a schemaLocation attribute with value:
http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd
… which is broken. Googling for web-app_2_5.xsd an XSD file is found but it doesn't contain the definition of <session-config> element (I couldn't locate it even when googling for the other XSDs that that file imports).
The specification does contain graphical depictions of some elements (in the horrible late 90's style when such "visualizations" were in vogue) but this is all it contains for the session-config element:
There's no futher discussion for the cookie-config element.
I find it hard to believe that a specification does not contain the full XSD (or at least a link to it) and a detailed description of the semantics of all elements and attributes.
Am I missing something?
A list of schemas can be found at
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html
(at the very beginning it is stated "Latest Version: http://xmlns.jcp.org/xml/ns/javaee/", which in turn redirects to the link I've posted first; I think the latter URL should be used as a permalink)
Then you'll find the schemas grouped by Java EE version. I think servlet 3.0 is JEE 6, so:
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html#6
There you'll get the schemas:
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-app_3_0.xsd
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-common_3_0.xsd
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-fragment_3_0.xsd
Had problems with the schemas from oracle. The URLs were just not working, kept throwing an error.
so I switched to the jboss schema (at https://www.jboss.org/j2ee/schema/)
I replaced
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
with
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee https://www.jboss.org/j2ee/schema/web-app_2_4.xsd"
Also make sure the version attribute on the web-app tag is set correctly (e.g. version="2.4" in this case)
Hi I want to add a query parameter Age = 23
I tried adding
message.inboundProperties.'http.query.params'.Age = '23'
In a expression
<expression-component doc:name="Expression"><![CDATA[message.inboundProperties.'http.query.params'.Age= '23';]]></expression-component>
It won't work.
Inbound properties are Immutable hence you must add it in outbound property to add a query param in your outbound http connector you can use the below
<http:request config-ref="HTTP_Request_Configuration" path="outway" method="POST" doc:name="HTTP">
<http:request-builder>
<http:query-param paramName="Age" value="23"/>
</http:request-builder>
</http:request>
To add properties to an outgoing message they need to be in the outbound scope:
message.outboundProperties.'http.query.params'.Age= '23'
You are trying to modify inbound properties but you can´t, they are inmutable
Properties have two main scopes: inbound and outbound.
Inbound properties are immutable, are automatically generated by the message source and cannot be set or manipulated by the user. They contain metadata specific to the message source that prevents scrambling of data formats or other processing mishaps later in the message’s lifecycle. A message retains its inbound properties only for the duration of the flow; when a message passes out of a flow, its inbound properties do not follow it (see image below).
https://docs.mulesoft.com/mule-fundamentals/v/3.7/mule-message-structure
You must add it to outbound as Ryan said.
I am trying to achieve the functionality where i have to call two different backends / target endpoints that have completely different interface in a sequence. Output of one call becomes input to the second one upon an error condition from the first call.
I would like to know how to implement this. I am new to Apigee so details will help me.
It sounds like you need to do a ServiceCallout in the request flow.
Set up your Target as whatever the second server is that you need to talk to in the normal flow. Then create a policy to callout to your first target:
<ServiceCallout name="myPolicy">
<Request clearPayload="false" variable="myRequest"/>
<Response>myResponse</Response>
<HTTPTargetConnection>
<Properties/>
<URL>http://example.com</URL>
</HTTPTargetConnection>
</ServiceCallout>
Note the Response block puts the headers and payload from the response into an object that you can then extract variables from using "myResponse" as the <Source> in the ExtractVariables policy.
Then you can build a new request for your target with the variables you set in the ExtractVariables by using an AssignMessage policy
Service Callout
http://apigee.com/docs/api-services/content/call-services-or-apis-using-servicecallout
ExtractVariables
http://apigee.com/docs/api-services/content/extract-message-content-using-extractvariables
AssignMessage
http://apigee.com/docs/api-services/content/generate-or-modify-messages-using-assignmessage
I have created a new API /v1/StatusCache to point to my end point /v1/Status. My goal is to be able to cache the data :
based on the uri
for a particular header
So if user 1 sends request to /v1/StatusCache/1234 and the same user sends request to /v1/StatusCache/5678, I should hit my server instead of getting previously cached result from the first request.
Also we user header (Authorization: Bearer ) in the request so my second goal is that if user 1 with header Authorization: Bearer token1 sends a request to /v1/StatusCache/1234 vs a user 2 with header Authorization: Bearer token2 sends a request to /v1/StatusCache/1234, I should get different results (non cached results)
I have this code for proxypath but it just caches every request for 10 seconds. What am I missing
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="responsecache-1">
<DisplayName>ResponseCache-1</DisplayName>
<FaultRules/>
<Properties/>
<CacheKey>
<Prefix/>
<KeyFragment ref="proxy.pathsuffix" type="string">proxy.pathsuffix</KeyFragment>
</CacheKey>
<Scope>Exclusive</Scope>
<ExpirySettings>
<ExpiryDate/>
<TimeOfDay/>
<TimeoutInSec ref="">10</TimeoutInSec>
</ExpirySettings>
<SkipCacheLookup/>
<SkipCachePopulation/>
</ResponseCache>
My suggestion would be create a variable value combining the header and pathsuffix value (header+pathsuffix) - use this as the key for the response cache.
Try the following:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="responsecache-1">
<DisplayName>ResponseCache-1</DisplayName>
<FaultRules/>
<Properties/>
<CacheKey>
<Prefix/>
<KeyFragment ref="proxy.pathsuffix" type="string"/>
<KeyFragment ref="request.header.Authorization" type="string"/>
</CacheKey>
<ExpirySettings>
<ExpiryDate/>
<TimeOfDay/>
<TimeoutInSec ref="">60</TimeoutInSec>
</ExpirySettings>
<SkipCacheLookup/>
<SkipCachePopulation/>
</ResponseCache>
I used 60 sec timeout for ease of testing.
This shows an example of proxy.pathsuffix + request.header.Authorization values being a unique cache key. Think of the key now looking like /1234__Bearer token1. The same path suffix and Authorization header value combined are needed to return an entry from cache.
Also, when trying to cache the URI, you may want to try the variable request.uri which includes the querystring-- this can sometimes dictate what the response looks like. If using this, be sure that the querystring does not include unique values like a current timestamp (or at least strip that parameter before using it as a cache key fragment).
<rdf:Description about='uuid:8949dbc6-31ad-11d9-9c7d-d112c21f7031'>
Why this about does not contain urn:uuid:8949dbc6-31ad-11d9-9c7d-d112c21f7031 instead? Isn't the uuid a urn, and therefore required to have a urn: scheme in front of it ?
Following the chain of specifications, the IANA URN namespace registry does indeed register 'uuid' as a namespace after 'urn:'. So yes, the URL above is wrong and it should start 'urn:uuid' as you were expecting.
This URI is wrong. Using the following RDF document in the W3C RDF Validator returns an error
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description about='uuid:8949dbc6-31ad-11d9-9c7d-d112c21f7031'>
<dc:title>Hello</dc:title>
</rdf:Description>
</rdf:RDF>
Error: {W102} unqualified use of rdf:about is deprecated.[Line = 4, Column = 70]