InCommon Operations Notifications

[John Krienke <>]

All,

An unexpected change was processed to the "Content-Type" field after this notice 
went out.
This is FYI only and NO ACTION IS REQUIRED. No service impact has been reported 
or is anticipated.

Issue: The Content Type was mistakenly changed from the reported 
"application/xml" to "application/samlmetadata+xml".

Action: InCommon will roll back to the old content-type as announced below 
during today's (July 30th) metadata signing around 3pm ET.

Reason: Even though it is likely that we will /eventually/ change the Content 
Type to support the new SAML Metadata specification, we will only do so after we 
have communicated the change in advance to InCommon Participants. We do not 
anticipate that a change or this rollback will cause any known software issues. 
That said, our goal is to proceed with changes to operational infrastructure 
with the utmost transparency and advance notice, which is why we are choosing to 
rollback and support the old content type until we are ready to announce a change.

If you experience any problems as a result of these changes, please email 
 with an urgent message.


john.

--

John CW Krienke
Chief Operating Officer, InCommon
Director, Internet2 Trust Services
http://www.incommon.org
http://www.internet2.edu



On 7/12/12 10:21 AM, Tom Scavo wrote:
> This information is being provided FYI only. NO ACTION IS REQUIRED on the 
> part of site administrators or technical contacts.
>
> On July 19, 2012 @ 2:00pm, InCommon Operations will modify the server 
> infrastructure on wayf.incommonfederation.org. (Recall that the Discovery 
> Service and InCommon metadata are served from wayf.incommonfederation.org.) 
> Specifically, we will remove Tomcat and use straight Apache.
>
> We've analyzed and compared the HTTP responses from the two servers. The 
> server responses are similar but there are two differences in the HTTP 
> response headers as noted below. The fact that Apache responds with a Server 
> response header shouldn't be a problem at all. The differences in the ETag 
> response headers are more significant. Note that Tomcat issues a weak ETag 
> header (http://en.wikipedia.org/wiki/HTTP_ETag) while Apache does not. We 
> don't think this will be a problem but we wanted to bring it to your 
> attention anyway. After July 19, please monitor your metadata refresh 
> processes to make sure there are no ill effects. If you detect a problem, 
> notify 
>
>  immediately.
>
> Thanks,
>
> Tom Scavo
> Operations Manager
> InCommon.org
> https://twitter.com/trscavo
>
> -----
>
> Tomcat:
>
> HTTP/1.1 200 OK
> Date: Wed, 20 Jun 2012 20:31:56 GMT
> Accept-Ranges: bytes
> ETag: W/"5077727-1340218724000"
> Last-Modified: Wed, 20 Jun 2012 18:58:44 GMT
> Content-Type: application/xml
> Content-Length: 5077727
> Connection: close
>
>
> Apache:
>
> HTTP/1.1 200 OK
> Date: Wed, 20 Jun 2012 21:30:22 GMT
> Server: Apache
> Last-Modified: Wed, 20 Jun 2012 18:58:44 GMT
> ETag: "f0808-4d7adf-4c2ebfcf72100"
> Accept-Ranges: bytes
> Content-Length: 5077727
> Connection: close
> Content-Type: application/xml