Header Parameters

Learn how to work with HTTP headers in moclojer. Access and use request headers in dynamic responses (Authorization, User-Agent, etc).

HTTP headers carry metadata about the request and response. In moclojer, you can access headers sent by the client and use them in dynamic responses, as well as define custom headers in responses.

What Are HTTP Headers?

Headers are key-value pairs sent in HTTP requests and responses:

GET /api/users HTTP/1.1
Host: localhost:8000
Content-Type: application/json
Authorization: Bearer token123
User-Agent: curl/7.64.1
Accept: application/json

Divided into:

  • Request Headers: Client β†’ Server

  • Response Headers: Server β†’ Client

Why Use Headers?

βœ… Authentication: Authorization: Bearer token βœ… Content Negotiation: Accept: application/json βœ… Caching: Cache-Control, ETag βœ… CORS: Access-Control-Allow-Origin βœ… Tracking: X-Request-ID, X-Correlation-ID βœ… Client Info: User-Agent, Referer


Accessing Request Headers

Syntax: {{header-params.HeaderName}}

Test:

Response:


Common Headers

1. Authorization (Authentication)

Request:

Response:

2. User-Agent (Client)

Request:

3. Content-Type

Request:

4. Accept (Content Negotiation)

Request JSON:

Request XML (simulated):

5. Custom Headers (X-*)

Request:


Defining Response Headers

Simple Headers

Test:

Response headers:

Dynamic Headers

Request:

Response headers include:

CORS Headers

Or use global flag:

Cache Headers


Practical Use Cases

1. Bearer Token Authentication

⚠️ Note: moclojer doesn't validate tokens. Both endpoints will respond. Use correct order or validation tools.

2. API Versioning via Header

Request v1:

Request v2:

3. Request Tracking

Request:

4. Multi-Tenant API

Request:

5. Rate Limiting Headers

6. Content Negotiation

Request:


Combining Parameters

Headers + Path + Query + Body

Request:


Headers Case-Insensitive

HTTP headers are case-insensitive:

But convention:

  • Use Title-Case in headers: Content-Type, Authorization

  • Use exactly as defined in template


Standard Headers vs Custom

Standard Headers (Avoid X- prefix)

RFC 6648 discourages X- in new headers:

But X- is still very common in practice:

  • X-Request-ID

  • X-Correlation-ID

  • X-API-Key

  • X-Forwarded-For

Custom Headers (Use specific prefix)


Best Practices

βœ… Do

  1. Use headers for metadata, not data

  2. CORS headers when needed

  3. Content-Type always explicit

  4. Request tracking headers

❌ Avoid

  1. Sensitive headers in logs

  2. Giant headers

  3. Complex data in headers


Troubleshooting

Problem: Header is not replaced

Cause: Incorrect name (case-sensitive in template)

Problem: Custom header doesn't appear

Cause: Not defined in response

Problem: CORS error

Solution:


Important Headers

Header
Usage
Example

Authorization

Authentication

Bearer token123

Content-Type

Body type

application/json

Accept

Desired format

application/json

User-Agent

Client info

curl/7.64.1

X-Request-ID

Request tracking

req-abc-123

X-API-Key

API key auth

sk_live_abc123

Cache-Control

Caching policy

max-age=3600

Location

Redirect/Created

/users/123


Next Steps

See Also

Last updated

Was this helpful?