Skip to Content.
Sympa Menu

metadata-support - Re: [Metadata-Support] MDQ format options?

Subject: InCommon metadata support

List archive

Re: [Metadata-Support] MDQ format options?

Chronological Thread 
  • From: Ian Young <>
  • To:
  • Subject: Re: [Metadata-Support] MDQ format options?
  • Date: Tue, 6 Dec 2016 21:13:55 +0000
  • Feedback-id:
  • Ironport-phdr: 9a23:/yhvjhzPDKM5u5PXCy+O+j09IxM/srCxBDY+r6Qd2+oVIJqq85mqBkHD//Il1AaPBtSAra8cwLSH+4nbGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1Ov71GonPhMiryuy+4ZPebgFGiTanYb5+MBq6oATVu8ILnYZsN6E9xwfTrHBVYepW32RoJVySnxb4+Mi9+YNo/jpTtfw86cNOSL32cKskQ7NWCjQmKH0169bwtRbfVwuP52ATXXsQnxFVHgXK9hD6XpP2sivnqupw3TSRMMPqQbwoXzmp8qFmQwLqhigaLT406GHZhM9sg61Urhyvuh5wzZDaYI+SL/dxZL/RfdYASGpBQspcVSpMCZ68YYsVCOoBOP5VoYrnqFsIsBCxBw6sBP7pyj9Hm3T72qw63P4nEQzd3QwvBdIPvG7TrNXvO6ceS/21zKrRwDjFcvhY1zD96I3SfRAgp/GBRbNwcczNxkkoEgPFi1KQqYr/MzOSzOQNvG6W5PdjW+K3k2MrtRx9ria1yssyhITFnJ8ZxkrZ+Slh3oo5ON+1RFRmbdOkEJZcrTyWOol4T884Xm1kpTo2x7sbspChZicK0o4oxxvHZvyHbYeI5hXjWf6KITd9nn1lYq6/hxa18Ui71u3wStS430xQoipAiNbMt3QN2wbS68eZTPtx5EGh1iiT1wzJ9+FEIlg4lavdK5E/3r49joQfvVndEiPshkn7grWaelg+9uS18+jnZ6/ppp6YN496kAH+NaEul9S+AesiNAgDRGmb9v681bH5+k35WrpKgucrkqnaqJzaP9gUpralAw9J1YYu8xe/DzG639QfmHkHKVVFeBSdg4juIVHOL+n0DfKhjFSwijhk2urJPqH7DZnUNXjDja/hfa56605G1Ao+1tRf55NPCrEdO/L/RFX9tN3eDh8lLQO02eDnB8th1o8AQ26AHLKWML6B+WOPs+ciP+CAbZMc/S3gM+Ai/eLGjHkynloYeq/v2oEYO16iGfEzAkyfKUvrn9EOWTMLtwwWTeX7zlqYXnhOZCDhDOoH+jgnBdf+Xs/4TYe3jenZ0Q==

On 6 Dec 2016, at 20:53, Tom Poage <> wrote:

Had a question from a puzzled SP user as to why MDQ response is presented as HTML when requested from a browser.

I explained to him it may have had to do with the Accept header sent by the browser:

GET /global/entities/foo HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

The (compliant) response being:

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8

Of course, something like curl sends:

Accept: */*

So yes, that's exactly how it is being determined. The browser says it prefers text/html, and that's one of the content types the implementation knows how to render, so that is what is returned.  The content type is decided by this part of the configuration:

Content negotiation strategy.
* Ignore file extension and format attribute.
* Use Accept header.
* Default to SAML metadata.
<property name="contentNegotiationManager">
<bean class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
<property name="favorPathExtension" value="false"/>
<property name="favorParameter" value="false"/>
<property name="ignoreAcceptHeader" value="false"/>
<property name="defaultContentType" value="application/samlmetadata+xml"/>

You can see the defaultContentType at the end there, which is used when the type isn't resolved, either because it hits a */* or in the case where no Accept header is sent.

This seemed like the best way to get something that was spec compliant and still behaved in a useful way when responding to a browser (the spec deliberately avoids talking about that case explicitly).

I briefly looked at the MDQ server source, and it didn’t immediately jump out at me, so ...

Q: Is it already possible to specify the desired format in the URL to obtain application/samlmetadata+xml?

E.g. something like


No, it's not currently possible. I intentionally suppressed the parameter handling option in the ContentNegotiationManagerFactoryBean because the spec didn't have anything like that in it.

It would be possible in principle to enable that mechanism and map something like ?format=raw to be equivalent to asking for application/samlmetadata+xml, but I'm not sure that's really what your SP user wants. The SP itself will always query with an appropriate Accept header, and if he wants to pull it manually it's a lot safer to use curl or wget than it is trusting a browser to save the file properly without breaking it in some way.

Not (necessarily) a feature request, just a question.

Hope that helps,

    -- Ian

Archive powered by MHonArc 2.6.19.

Top of Page