# Diagnostic : Erreurs 500 avec nostrimg.com

## Date
2025-01-27

## Problème
L'endpoint `https://nostrimg.com/api/upload` retourne systématiquement des erreurs 500 lors des tentatives d'upload.

## Vérifications effectuées du code

### 1. Format de la requête ✅
- **FormData** : Utilisation correcte du package `form-data` npm
- **Champ de fichier** : Nom de champ `'file'` (standard NIP-95)
- **Stream** : Utilisation de `fs.createReadStream()` pour lire le fichier
- **Filename** : Transmission du nom de fichier original ou généré
- **Content-Type** : Transmission du type MIME du fichier

### 2. Headers HTTP ✅
- **Content-Type** : Généré automatiquement par `form-data` avec le boundary correct
  - Format : `multipart/form-data; boundary=...`
- **Accept** : `application/json` (ajouté)
- **User-Agent** : `zapwall.fr/1.0` (ajouté)
- **Authorization** : Ajouté uniquement si token NIP-98 fourni (non requis pour nostrimg.com)

### 3. Configuration de la requête ✅
- **Méthode** : `POST` (correct)
- **URL** : `https://nostrimg.com/api/upload` (correcte)
- **Timeout** : 30 secondes (raisonnable)
- **Gestion des redirections** : Support des 301, 302, 307, 308

### 4. Gestion des erreurs ✅
- Détection des réponses HTML
- Classification des erreurs (404, 403, 500)
- Messages d'erreur clairs
- Logging amélioré

## Points à vérifier (non confirmés)

### 1. Nom du champ de fichier
- **Actuel** : `'file'`
- **Possible problème** : Certains endpoints NIP-95 utilisent `'image'`, `'upload'`, ou d'autres noms
- **Action** : Le code utilise `'file'` qui est le standard NIP-95, mais nostrimg.com pourrait attendre un autre nom

### 2. Format de la réponse attendue
- **Actuel** : Le code attend du JSON
- **Possible problème** : nostrimg.com pourrait retourner un format différent ou nécessiter des paramètres spécifiques

### 3. Authentification
- **Actuel** : Pas d'authentification pour nostrimg.com
- **Possible problème** : nostrimg.com pourrait nécessiter une authentification (NIP-98 ou autre)

### 4. Taille de fichier
- **Actuel** : Limite de 50MB côté proxy
- **Possible problème** : nostrimg.com pourrait avoir une limite différente

## Logging ajouté

Pour diagnostiquer le problème, un logging détaillé a été ajouté spécifiquement pour nostrimg.com :

### Logs de requête
- URL complète
- Méthode HTTP
- Nom du champ de fichier
- Nom du fichier
- Type MIME
- Taille du fichier
- Tous les headers (Content-Type, Accept, User-Agent, Authorization)

### Logs de réponse
- Code de statut HTTP
- Message de statut
- Headers de réponse (Content-Type, Content-Length)
- Aperçu du corps de la réponse (500 premiers caractères)
- Longueur du corps
- Détection HTML

## Prochaines étapes

1. **Activer nostrimg.com temporairement** et vérifier les logs serveur pour voir :
   - Les détails exacts de la requête envoyée
   - La réponse exacte du serveur nostrimg.com
   - Le code de statut et les headers de réponse

2. **Tester avec curl** pour comparer :
   ```bash
   curl -X POST https://nostrimg.com/api/upload \
     -H "Accept: application/json" \
     -H "User-Agent: zapwall.fr/1.0" \
     -F "file=@test.jpg"
   ```

3. **Vérifier la documentation** de nostrimg.com si disponible :
   - Nom de champ attendu
   - Headers requis
   - Format de réponse
   - Limites de taille

4. **Tester avec un nom de champ différent** si les logs indiquent un problème :
   - `'image'` au lieu de `'file'`
   - `'upload'` au lieu de `'file'`

## Conclusion

Le code semble correct selon les standards NIP-95 :
- ✅ Format multipart/form-data correct
- ✅ Headers HTTP appropriés
- ✅ Gestion des erreurs robuste
- ✅ Logging détaillé pour diagnostic

**Hypothèse principale** : Le problème semble être côté serveur nostrimg.com plutôt que dans notre code. Les logs détaillés permettront de confirmer ou d'infirmer cette hypothèse.

## Modifications

- **Fichier modifié** : `pages/api/nip95-upload.ts`
- **Logging ajouté** : Logs détaillés pour les requêtes et réponses vers nostrimg.com
- **Commentaire ajouté** : Note sur le nom de champ 'file' et alternatives possibles