HTTP/HTTPS Debugging Nightmare: Mixed Content Hell से गुज़रता 24-घंटे का सफर
मैंने 24 घंटे debug करने में बिताए कि मेरी React app HTTPS pages से HTTP requests क्यों कर रही थी — भले ही मेरा code उन्हें convert कर रहा था। Culprit ने मुझे shock कर दिया।
---
Update (November 2025): STRAŦUM अब Private Alpha में live है! इस post में mentioned 9-agent marketing platform early testers accept कर रहा है। stratum.chandlernguyen.com पर access request करें या full launch story पढ़ें।
---
Context: Marketing Platform Journey जारी है
वह September post याद है जहाँ मैंने कहा था कि मैं naps लेते हुए एक 10-agent marketing platform speed-run कर रहा हूँ? चार हफ्तों में, मेरे पास 3 working agents थे और October/November में alpha launch target था।
Well, अब late October है। Progress update का समय।
Good News:
- Platform का finally एक name है: STRAŦUM (Intelligence Over Execution)
- Complete brand guidelines और design system (turns out branding coding से ज़्यादा time लेती है)
- 9 of 10 agents built और integrated
- Multi-tenant architecture actually काम कर रही है
- Final stage: pre-alpha, invitation-only testing की तैयारी
Reality Check:
8 दिन leave पर रहने के बाद 10 दिन sick हो गया (मुझे पता है life happens।) इसने सब कुछ pause पर डाल दिया और timeline shift हो गई। वह October launch गया, है ना?
लेकिन solo development में यह बात है: आप pace control करते हैं। जब ready नहीं हों तब ship करने का pressure नहीं। कोई investors नहीं जो आपकी गर्दन पर साँस लें। बस... सही बनाओ।
यह blog post उन "build it right" moments में से एक के बारे में है जो 6-hour debugging marathon में बदल गया। क्योंकि ठीक जब मैं sick होने के बाद full speed पर वापस आ रहा था, मेरे deployment platform के अन्य plans थे।
जब AWS Down हो, तो Engineers Creative होते हैं (और कभी-कभी पछताते भी हैं)
यहाँ कुछ ऐसा है जो coding bootcamps में नहीं सिखाते: कभी-कभी आपका deployment platform बस... गायब हो जाता है। आपने कुछ गलत नहीं किया, लेकिन AWS ने global outage decide की जो Vercel deployments को globally affect करे।
ऐसे ही मेरा Monday शुरू हुआ। Production site down, Vercel errors show कर रहा था, और मेरे मन में एक ही विचार था: "मुझे एक backup चाहिए। Fast।"
Enter Cloudflare Pages। मैंने अच्छी बातें सुनी थीं। Great CDN, automatic deployments, simple setup। क्या गलत हो सकता था?
Narrator: सब कुछ। सब कुछ गलत हो सकता था।
वह Switch जो बहुत Easy लगी
Cloudflare Pages पर migration surprisingly smooth थी। GitHub repo connect किया, dashboard में environment variables set किए, main पर push किया। तीन मिनट बाद: deployed।
"वाह," मैंने सोचा। "यह almost too easy है।"
फिर मैंने production site open किया।
```
Mixed Content: The page at 'https://my-site.com/...' was loaded over HTTPS,
but requested an insecure resource 'http://stratum-api.us-central1.run.app/...'
```
वह sinking feeling जब आपको realize होता है कि आपका celebration premature था? हाँ, वही।
Problem: HTTPS Page से HTTP Calls
मेरी React app मेरे backend API को HTTP requests कर रही थी जबकि page खुद HTTPS पर load थी। Browsers (rightfully) इसे security risk के रूप में block करते हैं। Mixed Content errors। हर single API call fail हो रही थी।
"लेकिन रुको," मैंने खुद से कहा, "मेरे code में ensureHttpsInProduction() है! यह automatically HTTP को HTTPS में convert करना चाहिए!"
मैंने deployed bundle check किया। Function था। Logic correct था। Browser console conversion show कर रहा था। तो HTTP requests अभी भी क्यों आ रहीं थीं?
पहली Debugging Attempt: Environment Variable Hunt
शायद Cloudflare में environment variables pick नहीं हो रहे थे?
```bash
# Cloudflare Dashboard check किया
VITE_API_URL=https://stratum-api.us-central1.run.app ✓
VITE_SUPABASE_URL=https://your-project.supabase.co ✓
```
सब HTTPS। सब correct।
Rebuild trigger किया। Wait किया। Deploy किया। Site open किया।
Same error। अभी भी HTTP requests।
दूसरी Attempt: The Great Reimport
शायद files centralized API_BASE_URL use नहीं कर रही थीं?
मैंने अगला घंटा 24 files को update करने में बिताया @/lib/api से import के लिए। हर component जो API calls करता था उसे treatment मिली।
```typescript
// पहले
const response = await fetch(`${import.meta.env.VITE_API_URL}/api/v1/...`);
// बाद में
import \{ API_BASE_URL \} from '@/lib/api';
const response = await fetch(`$\{API_BASE_URL\}/api/v1/...`);
```
Push। Deploy। Wait।
अभी भी broken।
इस point पर, मैं अपनी life choices पर question करने लगा।
Plot Twist: Git में Missing Files
लेकिन रुको, और बुरा होना बाकी है।
यह investigate करते हुए कि मेरी HTTPS enforcement क्यों काम नहीं कर रही, मैंने कुछ terrifying discover किया। api.ts file जिसमें ensureHttpsInProduction() था वह मेरे Git repo में था ही नहीं।
authService.ts भी नहीं। csvSanitizer.ts भी नहीं। तीन critical frontend files, बस... missing।
कैसे? .gitignore file में यह था:
```
# Python stuff
lib/
build/
dist/
```
Python के लिए reasonable लगता है, है ना? सिवाय इसके कि मेरी frontend utilities apps/web/src/lib/ में रहती थीं। Broad lib/ pattern accidentally मेरी entire frontend lib directory को ignore कर रहा था!
Fix:
```diff
# .gitignore - पहले
-lib/
# .gitignore - बाद में
+apps/api/lib/ # Python-specific
+!apps/web/src/lib/ # Frontend lib explicitly include
```
Missing files add किए, commit किए, push किए। अब Cloudflare के पास HTTPS enforcement code था!
सिवाय इसके... HTTP errors जारी रहीं।
तीसरी Attempt: Build-Time Validation
इस point पर, मैं सब कुछ question कर रहा था। एक Vite plugin लिखा जो production में HTTP URLs detect होने पर build fail करता है:
```typescript
function validateProductionUrls(mode: string) \{
if (mode !== 'production') return;
const apiUrl = process.env.VITE_API_URL || '';
if (apiUrl && apiUrl.trim().startsWith('http://')) {
if (!apiUrl.includes('localhost') && !apiUrl.includes('127.0.0.1')) {
throw new Error(
`❌ HTTPS ENFORCEMENT FAILED
Environment Variable: VITE_API_URL
Current Value: ${apiUrl\}
This will cause Mixed Content errors in production!`
);
}
}
}
```
Genius, है ना? अब HTTP URLs के साथ deploy करना IMPOSSIBLE है।
Deploy किया। Build pass हुई। Site load हुई।
Same. Damn. Error.
Lightbulb Moment: Local Files Deploy हो रही थीं
बहुत देर (बहुत देर) शाम को, मुझे एक realization हुई।
मैंने deployed JavaScript bundle फिर से check किया। इस बार सच में देखा। URL यह था:
```javascript
"http://stratum-api.us-central1.run.app"
```
लेकिन मेरी Cloudflare environment variables HTTPS थीं। तो यह HTTP URL कहाँ से आ रही थी?
फिर मुझे hit हुआ। मेरी local .env.production file।
```bash
# apps/web/.env.production (LOCAL FILE)
VITE_API_URL=http://stratum-api.us-central1.run.app
```
Cloudflare Pages dashboard variables की जगह मेरी local environment file deploy कर रही थी!
मैंने .cloudflare-pages-ignore check किया:
```
# Environment files
.env
.env.local
.env.development
.env.test
# .env.production ← MISSING!
```
Face. Palm.
Fix: एक Line
```diff
# apps/web/.cloudflare-pages-ignore
.env
.env.local
.env.development
.env.test
+.env.production
```
Deploy। Wait।
इस बार different error! Progress!
```
Access to fetch at 'https://stratum-api.us-central1.run.app/...'
from origin 'https://preview-xyz.stratum-marketing-suite.pages.dev'
has been blocked by CORS policy
```
CORS errors! Beautiful, beautiful CORS errors! इसका मतलब HTTPS काम कर रहा था!
लेकिन रुको, और है: The Cache Conspiracy
CORS fix किया। Deploy किया। Custom domain open किया।
HTTP errors फिर।
क्या?!
Turns out, Cloudflare का CDN old bundle को aggressively cache कर रहा था।
Cloudflare के cache purging के लिए चाहिए:
1. सही zone settings ढूंढना (Pages dashboard में नहीं) 2. Domain settings navigate करना (obvious नहीं) 3. Manually cache purge करना (हर deployment के लिए)
HTTP/HTTPS issues को घंटों debug करने के बाद, मैंने एक decision लिया।
Vercel पर वापसी: कभी-कभी Boring बेहतर है
AWS back up था। Vercel फिर से काम कर रहा था।
मैंने सब कुछ Vercel पर वापस migrate किया। क्यों?
1. Automatic cache invalidation - Manual purging की ज़रूरत नहीं 2. Simpler environment variable handling - जो set करो वही मिलता है 3. Faster debugging - Reason करने के लिए कम infrastructure 4. Battle-tested - मैं इसकी quirks जानता हूँ
Vercel deployment में 3 मिनट लगे। कोई HTTP errors नहीं। कोई cache issues नहीं। बस... काम किया।
मैंने क्या सीखा (The Hard Way)
1. हमेशा .env.production को Deployment Platforms में Ignore करें
```
# .vercelignore
# .cloudflare-pages-ignore
# .netlify-ignore
.env
.env.local
.env.development
.env.test
.env.production ← यह मत भूलो
```
2. Broad .gitignore Patterns Monorepos में Dangerous हैं
```diff
# ❌ Bad - Frontend AND Backend lib folders ignore करता है
-lib/
-build/
-dist/
# ✅ Good - हर context के लिए specific
+apps/api/lib/ # Python-specific
+apps/api/build/
+apps/api/dist/
+apps/web/dist/ # Siर्फ Vite output
```
Always पूछें: "क्या यह pattern accidentally कुछ important ignore कर सकता है?"
3. Build-Time Validation अभी भी Worth It है
भले ही इसने local file issue catch नहीं की, build-time validation *future* misconfigurations को prevent करती है।
4. Multi-Layer Defense काम करता है
हमारी final architecture में THREE layers हैं:
- Build-time: HTTP URLs detect होने पर build fail - Runtime: HTTPS पर load होने पर HTTP → HTTPS convert - Deployment: Local .env files exclude
5. Preview URLs आपके दोस्त हैं
हमेशा पहले preview URL पर test करें। अगर वह काम करे लेकिन custom domain नहीं, तो usually caching है।
6. Platform की Quirks जानें
- Vercel: Simple, auto-invalidates cache, environment variables "just work" - Cloudflare Pages: Great CDN, लेकिन manual cache purging और complex setup
वह Code जिसने मुझे Saved किया
यहाँ final ensureHttpsInProduction() function है:
```typescript
function ensureHttpsInProduction(url: string): string \{
if (typeof window !== 'undefined' && window.location.protocol === 'https:') {
if (url.startsWith('http://') &&
!url.includes('localhost') &&
!url.includes('127.0.0.1')) {
console.warn('[API] Converting HTTP to HTTPS:', url);
return url.replace('http://', 'https://');
\}
}
return url;
}
```
Real Lesson: Debugging Detective Work है
यह coding problem नहीं था। यह configuration archaeology expedition था।
Real bugs थे:
1. ✅ Broad .gitignore patterns critical frontend files ignore कर रहे थे
2. ✅ .cloudflare-pages-ignore में .env.production missing था
3. ✅ Aggressive CDN caching fix को mask कर रही थी
4. ✅ Environment variable precedence assume करना
Technical solution एक .ignore file में एक line था।
Debugging? 6 घंटे, 14 deployments, और बहुत ज़्यादा coffee।
क्या यह Worth It था?
बिल्कुल। मैंने यह gain किया:
1. Deep understanding Mixed Content security policies की 2. Build-time validation जो future issues prevent करती है 3. Multi-layer HTTPS enforcement जो platform-agnostic है 4. Real appreciation Vercel की simplicity के लिए
और most importantly: share करने के लिए एक great debugging story। :P
अभी भी Coding, अभी भी Learning, अभी भी चीज़ें Break करना (कभी-कभी)
Six hours of debugging, एक-line fix के लिए। Software engineering यही है।
जो code हम ship करते हैं वह important है, sure। लेकिन जो debugging skills हम develop करते हैं? वे हमें better engineers बनाती हैं।
अगली बार जब मेरा deployment platform down हो (और होगा), मैं ready रहूँगा।
क्या आपके पास कभी एक "one-line fix" था जिसे ढूंढने में embarrassingly लंबा time लगा? मुझे आपकी debugging detective stories सुनना अच्छा लगेगा!
शुभकामनाओं सहित,
Chandler
