How to Fix “Server Doesn’t Support Byte-Range Requests” Error for Podcast Hosting


2 views

When iTunes reports "your server doesn't support byte-range requests," it's referring to HTTP's Range header functionality (RFC 7233). This allows clients to request specific portions of a file rather than downloading entire episodes, crucial for:

  • Podcast streaming (seeking without full download)
  • Resume functionality for interrupted downloads
  • Bandwidth optimization for mobile clients

For Apache servers (.htaccess or httpd.conf):


<IfModule mod_headers.c>
    Header set Accept-Ranges bytes
</IfModule>

For Nginx configurations:


location ~ \.(mp3|mp4)$ {
    add_header Accept-Ranges bytes;
    # For MP4 seeking support
    mp4;
    mp4_buffer_size 1m;
    mp4_max_buffer_size 5m;
}

Use curl to verify byte-range support:


curl -I -H "Range: bytes=0-100" https://yourdomain.com/podcast.mp3

Look for these response headers:


HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 0-100/1234567
  • CDN Issues: Some CDNs disable range requests by default - check your provider's documentation
  • File Permissions: Ensure your media files have correct read permissions (644 typically)
  • HTTP/2 Considerations: Some older HTTP/2 implementations may need explicit range support configuration

For AWS S3 bucket policies:


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your-podcast-bucket/*"
        }
    ]
}

Combine with CORS configuration for web playback:


<CORSConfiguration>
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <AllowedHeader>Range</AllowedHeader>
        <ExposeHeader>Content-Range</ExposeHeader>
    </CORSRule>
</CORSConfiguration>

When iTunes reports "your server doesn't support byte-range requests," it means your HTTP server isn't properly configured to handle partial content requests. Byte-range requests (HTTP 206 responses) are essential for:

  • Podcast clients that need to resume downloads
  • Mobile apps that stream audio progressively
  • Seek functionality in media players

Apache Web Server

Add this to your .htaccess or virtual host config:


    Header set Accept-Ranges bytes

Nginx Configuration

Add to your server block:

location ~ \.(mp3|mp4|m4a)$ {
    add_header Accept-Ranges bytes;
    mp4;
    mp4_buffer_size 1m;
    mp4_max_buffer_size 5m;
}

Node.js Express Server

For custom media servers:

const express = require('express');
const fs = require('fs');
const app = express();

app.get('/podcast/:file', (req, res) => {
    const filePath = ./media/${req.params.file};
    const stat = fs.statSync(filePath);
    const fileSize = stat.size;
    const range = req.headers.range;
    
    if (range) {
        const parts = range.replace(/bytes=/, "").split("-");
        const start = parseInt(parts[0], 10);
        const end = parts[1] ? parseInt(parts[1], 10) : fileSize-1;
        
        res.writeHead(206, {
            'Content-Range': bytes ${start}-$/${fileSize},
            'Accept-Ranges': 'bytes',
            'Content-Length': end-start+1,
            'Content-Type': 'audio/mpeg'
        });
        
        fs.createReadStream(filePath, {start, end}).pipe(res);
    } else {
        res.writeHead(200, {
            'Content-Length': fileSize,
            'Content-Type': 'audio/mpeg'
        });
        fs.createReadStream(filePath).pipe(res);
    }
});

Use curl to verify:

curl -I -H "Range: bytes=0-100" https://yourdomain.com/podcast.mp3

Look for these headers in response:

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 0-100/1234567

For AWS S3 buckets, enable these CORS settings:

[
    {
        "AllowedHeaders": ["*"],
        "AllowedMethods": ["GET", "HEAD"],
        "AllowedOrigins": ["*"],
        "ExposeHeaders": ["Content-Range"]
    }
]
  • CDN configurations may override origin server settings
  • Firewalls or security plugins might block range headers
  • Compression settings can interfere with partial content