github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 00:22:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[PR #15512] fix: handle HTTP 200 OK directly in OCI blob download (no Location header) #41055

New Issue
Open
opened 2026-04-23 01:47:53 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-23 01:47:53 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/15512
Author: @DubstepDuck
Created: 4/12/2026
Status: 🔄 Open

Base: main ← Head: fix/oci-200-redirect

📝 Commits (1)

  • 9067b33 fix: handle HTTP 200 OK directly in blob download without seeking location header

📊 Changes

1 file changed (+6 additions, -0 deletions)

View changed files

📝 server/download.go (+6 -0)

📄 Description

Hi everyone! 👋 This is my first ever pull request on GitHub, so please let me know if I need to adjust anything.

I was trying to set up my own local registry:2 to host my models and kept running into this error during pulls: http: no Location header in response. After debugging this for a while, I found the issue in server/download.go.

What's causing the bug?
Right now, the code explicitly allows http.StatusOK alongside http.StatusTemporaryRedirect. But right after that check, it blindly calls resp.Location().
If a registry serves the blob directly with a 200 OK response, there is no Location header. This causes net/http to throw an error, and the pull just fails entirely.

The Fix
This PR simply returns the original resp.Request.URL if a 200 OK is received. This bypasses the strict location header check when the registry serves the blob directly.

Steps to reproduce the issue:

  1. Host a standard registry:2 image and set REGISTRY_STORAGE_REDIRECT_DISABLE=true.
  2. Run ollama push to upload a model to it.
  3. Run ollama pull for the same model. It fails instantly with the Location header error.

Testing:
I compiled and tested this locally on macOS. With this small change, the pull smoothly downloads the chunks via the direct URL instead of failing on the header check. registry:2 is sitting behind a Nginx Proxy Manager in my setup, so I was using it's URL and https when testing.

Hope this helps! Let me know if you need me to change anything.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ollama/ollama/pull/15512 **Author:** [@DubstepDuck](https://github.com/DubstepDuck) **Created:** 4/12/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/oci-200-redirect` --- ### 📝 Commits (1) - [`9067b33`](https://github.com/ollama/ollama/commit/9067b335080fec266462e417645a811e8fc6cf53) fix: handle HTTP 200 OK directly in blob download without seeking location header ### 📊 Changes **1 file changed** (+6 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `server/download.go` (+6 -0) </details> ### 📄 Description Hi everyone! 👋 This is my first ever pull request on GitHub, so please let me know if I need to adjust anything. I was trying to set up my own local **registry:2** to host my models and kept running into this error during pulls: `http: no Location header in response`. After debugging this for a while, I found the issue in `server/download.go`. **What's causing the bug?** Right now, the code explicitly allows `http.StatusOK` alongside `http.StatusTemporaryRedirect`. But right after that check, it blindly calls `resp.Location()`. If a registry serves the blob directly with a 200 OK response, there is no Location header. This causes net/http to throw an error, and the pull just fails entirely. **The Fix** This PR simply returns the original `resp.Request.URL` if a 200 OK is received. This bypasses the strict location header check when the registry serves the blob directly. **Steps to reproduce the issue:** 1. Host a standard **registry:2** image and set `REGISTRY_STORAGE_REDIRECT_DISABLE=true`. 2. Run `ollama push` to upload a model to it. 3. Run `ollama pull` for the same model. It fails instantly with the Location header error. **Testing:** I compiled and tested this locally on macOS. With this small change, the pull smoothly downloads the chunks via the direct URL instead of failing on the header check. **registry:2** is sitting behind a Nginx Proxy Manager in my setup, so I was using it's URL and https when testing. Hope this helps! Let me know if you need me to change anything. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-23 01:47:53 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#41055
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?