search

ebu / radiodns-manager

The RadioDNS Manager is platform which can manage Hybrid Radio services such as RadioVIS, RadioEPG and Service Following
http://ebu.io/project/radiodns/
GNU General Public License v3.0
15 stars 3 forks source link

SI URLs are performing an unacceptable redirect #205

Closed andybee closed 3 years ago

andybee commented 3 years ago

When requesting an SI document (e.g. http://sirtvs.epg.radio.ebu.io/radiodns/spi/3.1/SI.xml) the following redirect occurs:

HTTP/1.1 301 MOVED PERMANENTLY
Connection: keep-alive
Content-Length: 419
Content-Type: text/html; charset=utf-8
Date: Wed, 17 Mar 2021 10:54:05 GMT
Location: https://d2qydwcycui0ka.cloudfront.net/5cb6ab6707a080ecee53413fd98c19942b9435d34db82bcc5be3ed9577809139.xml
Server: nginx/1.15.7

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="https://d2qydwcycui0ka.cloudfront.net/5cb6ab6707a080ecee53413fd98c19942b9435d34db82bcc5be3ed9577809139.xml">https://d2qydwcycui0ka.cloudfront.net/5cb6ab6707a080ecee53413fd98c19942b9435d34db82bcc5be3ed9577809139.xml</a>.  If not click the link.

Although it is valid within the SPI specification to redirect, the URL must be HTTP for a request originating from a _radioepg._tcp SRV lookup.

magicbadger commented 3 years ago

This will be more of an implementation question for the EBU service, rather than a bug in the code, although happy to discuss here.

Looking at ETSI TS 102 818, I can see:

10.5.1 General
Because documents are returned via HTTP or HTTPS, the HTTP specification [3] should be correctly implemented.
Attention is particularly drawn to the status codes section, which may be used to indicate problems and failures during
attempts to retrieve documents.
In particular, the following behaviours shall be adhered to:
• a device shall correctly follow any HTTP redirects that are returned when retrieving a document;
• a device shall respect any indicated document expiry in the HTTP response;
• it is recommended that devices cache retrieved documents, as per the HTTP specification.

This suggests this redirect is valid, unless you can see a conflict with the RadioDNS Core Lookup specification?

andybee commented 3 years ago

The issue isn't with the use of redirect, but the fact that the redirect moves the request from HTTP to HTTPS.

My understanding is that a request that starts over HTTP should not migrate to HTTPS to ensure a receiver without SSL support can understand the response. If, however, the request started over HTTPS, this is not an issue.

In my test request I ensured the client was not indicating HTTPS support via headers etc.

magicbadger commented 3 years ago

I'm not aware of a hard and fast rule here, and a very brief search shows that it does happen. Some people warn its not a good idea.

Again, this likely an implementation issue, so I can take it back to the EBU.