Accept a case-insensitive Bearer prefix on the config API - #250
Conversation
The gateway already treats `bearer token` as valid. The Python config service only stripped a capital Bearer prefix, so the same header 401ed.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughChangesAuthorization token parsing
Merge Risk: ⚪ Minimal · up to The configuration API now accepts case-insensitive, whitespace-tolerant Bearer authorization prefixes while retaining raw-token and invalid-token behavior. No current merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Hi @gyanu2507, thank you for the contribution! Sorry for the radio silence, we've been revamping our internal workflows that delayed a response on this PR. We can pick this up for a review early next week. |
|
Thanks for the update. No rush from my side. Happy to wait until next week. |
Summary
The gateway already accepts
bearer <token>(RFC 7235). The Python config service only stripped a capitalBearerprefix, so the same header that works on inference returned 401/403 on/v1/configs.One helper now trims, strips a case-insensitive Bearer prefix, and still accepts a raw token with no scheme.
Test plan
Authorization: bearer <admin>reaches/v1/configs/exportBEARERwith extra spaces also worksSummary by CodeRabbit
Bug Fixes
Tests