Allow HTTP 0.9 loads for requests to default ports

• Component: WebCore Misc.
• Status: RESOLVED WONTFIX

[Daniel Bates]

Following the fix for bug #158589 we no longer load HTTP 0.9 resources. This policy is too stringent and prevents loading Shoutcast/Icecast streams served over default ports. For compatibility we should allow Shoutcast/Icecast streams served over default ports.

[Daniel Bates]

<rdar://problem/29167064>

[Daniel Bates]

(In reply to comment #0)
> Following the fix for bug #158589 we no longer load HTTP 0.9 resources. This
> policy is too stringent and prevents loading Shoutcast/Icecast streams
> served over default ports. For compatibility we should allow
> Shoutcast/Icecast streams served over default ports.

Actually, this bug does not need to be specific to Shoutcast/Icecast streams. Instead this bug should be about allowing HTTP 0.9 loads for requests to default ports. This will allow loading Shoutcast/Icecast streams over default ports among other benefits.

[Daniel Bates]

Created attachment 294200 [details]
Patch and layout test

This patch modifies the test results added in the patch for bug #164389 and bug #164387. It also adds a new test to the directory added in the patch for bug #164389. Neither the patch for bug #164389 nor bug #164387 has landed as of the time of writing.

[Alexey Proskuryakov]

Comment on attachment 294200 [details]
Patch and layout test

View in context: https://bugs.webkit.org/attachment.cgi?id=294200&action=review

> Source/WebCore/ChangeLog:10
> +        loading from a Shoutcast/Icecast server on a default port among other benefits.

This is not the right fix for shoutcast streams, which are normally served over weird ports. So, I do not see why this change is desirable.

[Alexey Proskuryakov]

I think that the right fix for shoutcast would be to check the protocol in response.

[Daniel Bates]

(In reply to comment #4)
> Comment on attachment 294200 [details]
> Patch and layout test
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=294200&action=review
> 
> > Source/WebCore/ChangeLog:10
> > +        loading from a Shoutcast/Icecast server on a default port among other benefits.
> 
> This is not the right fix for shoutcast streams, which are normally served
> over weird ports. So, I do not see why this change is desirable.

I take it you feel that there is little compatibility risk to blocking subresources served with an HTTP 0.9 response?

[Leo A]

The proposed solution doesn't go far enough. Shoutcast is often run on non-standard ports because older versions of Shoutcast (Shoutcast 1, of which there are hundreds of thousands of instances) can only run multiple internet radio stations from the name IP address by placing them on separate ports. 

The fix MUST be to allow any Shoutcast/Icecast stream on any port however specified. Anything less than this, would not be an acceptable resolution to the bug.

[Alexey Proskuryakov]

> I take it you feel that there is little compatibility risk to blocking subresources served with an HTTP 0.9 response?

As of now, the ChangeLog claims that this "will allow loading from a Shoutcast/Icecast server on a default port among other benefits."

What I'm saying is that this won't help Shoutcast/Icecast in practice, and that I don't know what the other benefits are. I haven't seen any bug reports about other issues, but if there are any, please explain those in ChangeLog (and please also take out mentions of SHOUTcast).

[Daniel Bates]

(In reply to comment #7)
> The proposed solution doesn't go far enough. Shoutcast is often run on
> non-standard ports because older versions of Shoutcast (Shoutcast 1, of
> which there are hundreds of thousands of instances) can only run multiple
> internet radio stations from the name IP address by placing them on separate
> ports. 
> 
> The fix MUST be to allow any Shoutcast/Icecast stream on any port however
> specified. Anything less than this, would not be an acceptable resolution to
> the bug.

You're right! We'll fix this in <rdar://problem/28734311>.