Session File Conventions

This rule applies to files matching the patterns above.

# Session File Conventions

## Rule
Use named sessions for API workflows that require persistent authentication. Store sessions per environment. Never commit session files containing tokens or cookies to version control.

## Format
```bash
# Create/use a named session
http --session=dev GET api.example.com/users

# Session files stored in ~/.config/httpie/sessions/
# Structure: <host>/<session-name>.json
```

## Good Examples
```bash
# Login and save session
http --session=staging POST api.staging.example.com/auth/login \
  email=admin@example.com password=secret

# Subsequent requests reuse auth token automatically
http --session=staging GET api.staging.example.com/users
http --session=staging POST api.staging.example.com/orders name="Test"

# Separate sessions per environment
http --session=dev GET api.dev.example.com/health
http --session=prod-readonly GET api.example.com/status

# Read-only session (never writes updates)
http --session-read-only=prod GET api.example.com/users
```

## Bad Examples
```bash
# BAD: Repeating auth header on every request
http GET api.example.com/users "Authorization: Bearer eyJhbG..."
http GET api.example.com/orders "Authorization: Bearer eyJhbG..."
# Use a session instead

# BAD: Committing session files
git add ~/.config/httpie/sessions/  # Contains tokens!
```

## Gitignore Session Files
```gitignore
# .gitignore
.httpie/
**/httpie/sessions/
```

## Enforcement
- Add httpie session directories to .gitignore
- Use --session-read-only for production environments
- Rotate session tokens regularly — sessions persist until manually cleared