minimum viable solution options

[ijmitch]

Basic principles

Deciding what to return in response to an OPTIONS request is not really a job for an application to handle.

I've refactored the options into separate issues for discussion:

• New URM - issue Solution Option - New URM #4
• Content from zFS file inferred from URIMap name - issue Solution Option - Content from zFS file inferred from URIMap name #6
• Content from zFS file defined via new URIMap attribute - issue Solution Option - Content from zFS file determined by URIMap attribute #5

All options would suppress the DFHWB0762 message.

[Karagines]

Initial thoughts after reviewing the Liberty documentation left me leaning toward the URIMAP. The domain in the CORS definition matches the path in the URIMAP. The CORS definition should not be in the URIMAP itself if the unfavoured alternative were considered. It should instead point to a separate resource definition or hfs configuration file so that the CORS parameters could be shared across multiple URIMAPs. The CORS parameters are limited in nature so a CORS resource definition is plausible. I say this having no idea surrounding the effort to implement a new resource definition, CORS and adding a new parameter field (CORS) to an existing resource definition, URIMAP.

<cors domain="/sampleApp/path"
      allowedOrigins="https://alice.com:8090"
      allowedMethods="GET, DELETE, POST"
      allowedHeaders="accept, MyRequestHeader1"
      exposeHeaders="MyResponseHeader1"
      allowCredentials="true"
      maxAge="3600" />

As for the favoured alternative of DFHWBOPT, I could see where this has the advantage of being much quicker to market plus the advantage of customers being able to choose the repository for the CORS definitions. The one disadvantage I can see is the disassociation between the path of the URIMAP and the domain of CORS definition in URM. For those web services requiring CORS support, both the URIMAP and URM would need to be updated. This effort is roughly the same as the unfavoured alternative. But after implementation, it isn't readily apparent or easy to discover that CORS support is implemented for the web service using the URM method. Each shop would implement it differently.

And this isn't to say that both are exclusive of each other. DFHWBOPT would provide more immediate relief and has little overhead. The URIMAP solution could be longer term and provide a means to discover the environment more readily for CORS implementations. I was going to say audit but that would require a method to disable/ignore CICS applications returning CORS headers.

[DeadHam]

Here are a couple example cors rules that AWS S3 uses. The elements and there meaning are described here.

<CORSConfiguration>
 <CORSRule>
   <AllowedOrigin>http://www.example1.com</AllowedOrigin>
   <AllowedMethod>PUT</AllowedMethod>
   <AllowedMethod>POST</AllowedMethod>
   <AllowedMethod>DELETE</AllowedMethod>
   <AllowedHeader>*</AllowedHeader>
 </CORSRule>
 <CORSRule>
   <AllowedOrigin>http://www.example2.com</AllowedOrigin>
   <AllowedMethod>PUT</AllowedMethod>
   <AllowedMethod>POST</AllowedMethod>
   <AllowedMethod>DELETE</AllowedMethod>
   <AllowedHeader>*</AllowedHeader>
 </CORSRule>
 <CORSRule>
   <AllowedOrigin>*</AllowedOrigin>
   <AllowedMethod>GET</AllowedMethod>
 </CORSRule>
</CORSConfiguration>

<CORSConfiguration>
 <CORSRule>
   <AllowedOrigin>http://www.example.com</AllowedOrigin>
   <AllowedMethod>PUT</AllowedMethod>
   <AllowedMethod>POST</AllowedMethod>
   <AllowedMethod>DELETE</AllowedMethod>
   <AllowedHeader>*</AllowedHeader>
  <MaxAgeSeconds>3000</MaxAgeSeconds>
  <ExposeHeader>x-amz-server-side-encryption</ExposeHeader>
  <ExposeHeader>x-amz-request-id</ExposeHeader>
  <ExposeHeader>x-amz-id-2</ExposeHeader>
 </CORSRule>
</CORSConfiguration>