Newsgroup: it.comp.software.newsreader
Titolo: 441 header line too long.

Buongiorno a tutti e spero di essere nel NG giusto.
 
Stamane, per la prima volta in tanti anni che utilizzo Outlook Express 6.0 
per accedere ai NG, cercando di rispondere ad un post mi � comparso per la 
prima volta il messaggio di errore di cui all'oggetto, e non c'� stato verso 
di effettuare l'invio.
Da una ricerca in internet mi sembra di aver capito quanto segue :
- primo :  tale errore compare quando si tenta di inviare un messaggio che 
nell'header presenta una riga con numero di caratteri superiori al 
consentito ( mi sembra di ricordare 998 ), ed effettivamente controllando 
l'header del messaggio, la riga " References: " risultava composta da 1001 
caratteri, spazi compresi.
- secondo : mentre la normativa in materia pone una limitazione in termini 
di caratteri nelle stessa riga, non pone vincoli in termini di numero delle 
righe e quindi, se il newsreader in uso � in grado di farlo, l'eventuale 
superamento della massima lunghezza prevista potrebbe essere gestito con la 
generazione di pi� righe
- terzo : Outlook Express, non ho capito se per un baco o per sua 
limitazione funzionale, non � in grado di gestire in mdo " intelligente " il 
verificarsi dello sforamento del numero di caratteri ammessi per riga, con 
le conseguenze in cui sono occorso.
 
Capisco benissimo che Outlook Express oggi come oggi non � certo il massimo 
per�, mentre valuto a quale altro programma passare, chiedo se qui c'� 
qualcuno in grado di confermare se Outlook Express presenta effettivamente 
la " limitazione " che ho descritto e se esistono modi per superarla.
 
Nel caso specifico, l'unico modo che mi ha consentito di superare la 
situazione � stato di accodare la mia risposta ad un messaggio precedente, 
informando l'interlocutore del problema incontrato e del ricorso da parte 
mia a questo escamotage per aggirarlo.
 
Grazie a chi vorr� fornirmi risposte.
 
+1
 
 

 la " limitazione " che ho descritto e se esistono modi per superarla.
 
http://insideoecom/problems/errors.htm#line3
 
 
Ma ï¿œ una "pezza" da usare una tantum, non certo una
soluzione.
 
Bye, G.


Un saluto anche a te.
 
+1
 
 

 potrebbe essere gestito con la generazione di pi� righe
 
Anche con il testo distribuito in multiline, il risultato non cambia, le
RFC lo riferiscono ad un singolo campo.
Inoltre OE, in tal caso, rispetta lo standard di cui sopra.
 
Tieni presente che qualora un NR sforasse quel limite, sarebbe poi il
server a rifiutare il messaggio.
 
    ..._skipped!_
-- 
    * b *       Il tuo post � privo del MIME, attivalo in OE.
  *   y   *       Per impostare correttamente Outlook Express
*   Piero   *       e OE-QuoteFix, puoi consultare Wikipedia:
#v+
http://wiki.news.nic.it/GuidaNr_2fOutlookExpress?action=recall&date=1172714805
 
#v- 
 

 server a rifiutare il messaggio.
 
Aggiungo che OE, per ovviare al problema, si limita ad eliminare un MID.
Almeno a me fa questo.
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-beati monocoli in terra caecorum-
#v-
 
 


Quindi il problema che ho rilevato non � da attribuirsi ad una 
limitazione/carenza di OE, come mi era parso di intendere dalle 
informazioni che ho reperito in rete, ma al server che seguendo 
correttamente le RFC si rifiuta di processare messaggi con campi 
nell'header aventi numero di caratteri superiore al massimo consentito, 
anche se disrtibuiti su diverse righe.
E' corretto ?
 
+1
 


Scusami ma questo passaggio non mi � chiaro.
Che significa " si limita ad eliminare un MID " ?
 
+1
 

 server a rifiutare il messaggio.
 
Ed � cos�; infatti quello � l'errore restituito
dal server ad OE e che OE mostra all'utente.
 
Bye, G. 
 
 

 **************
 
Ok ne prendo atto, mi ricordavo il contrario, controlla per� che quella
RFC non sia stata classificata come obsoleta.


 Che significa " si limita ad eliminare un MID " ?
 
Significa che eliminando un MID si accorcia il testo, quindi il messaggio
parte.
 
A tal proposito Fidolook, che uso, permette il multiline, cio� mette i
singoli MID su ogni linea, e per esperienze avute, quando mi ritorna il
messaggio "441 header line too lon" uso quella feature, e se vado a
controllare vedo che viene eliminato un MID.
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-deus ex machina-
#v-
 
 

 E' corretto ?
 
Per quanto riguarda OE � corretto, perch� OE si comporta cos�.
Pi� sotto c'� il post di Paperino che facendo riferimento alla [RFC5322]
conferma che il limite si riferisce alla singola riga e non a tutto il
campo.
 
Ok, io mi ricordavo il contrario, purtroppo non ho tempo di controllare
se quella RFC � sempre valida oppure � diventata obsoleta.
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
Guardo il cielo e sorrido, spero in una foto satellitare.
#v-
 
 

 RFC non sia stata classificata come obsoleta.
 
Obsoleta no, ï¿œ stata aggiornata con la rfc6854,
ma le modifiche si limitano agli header To: e CC:,
in cui ï¿œ stata aggiunta e/o modificata la sintassi
per Group, e qualche altra cosa.
 
Bye, G.

 per Group, e qualche altra cosa.
 
Grazie, mi hai risparmiato la ricerca. :-)
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-do ut des-
#v-
 
 

 � stato fermato da... boh, saranno otto anni ?
[...]
 
Il problema non � che lo sviluppo sia fermo da otto anni, il problema � che
otto anni fa OE faceva schifo. :)
 
La versione di Dialog che uso sar� vecchia di una decina di anni ma �
sempre perfetta e, da quello che ne so, rimane il pi� completo newsreader
per windows sulla piazza (almeno tra quelli free).

 **************
 
Vedi questo punto rilevato dalla RFC 5536
 
2.2.3.  Long Header Fields
 
   Each header field is logically a single line of characters comprising
   the field name, the colon, and the field body.  For convenience
   however, and to deal with the 998/78 character limitations per line,
   the field body portion of a header field can be split into a
   multiple-line representation; this is called "folding".  The general
   rule is that wherever this specification allows for folding white
   space (not simply WSP characters), a CRLF may be inserted before any
   WSP.
 
non � molto chiaro e non lo specifica, ma non lo si pu� interpretare che,
pur splittando il testo in multiline, il "campo" debba comunque rispettare
il limite di 998 caratteri?
 
Considerando che viene splittato ogni singolo MID preceduto da uno spazio
e seguito dal fine linea con ritorno a capo "CRLF", c� da domandarsi perch�
i NR non distribuiscano i MID semplicemente su due righe.
 
Ti dico questo perch� in tal caso nelle references ci si potrebbe scrivere
un romanzo, e poi anche nelle multiline, non ho mai riscontrato il
superamento di quel limite...


 superamento di quel limite...
 
Eh... qualche tempo fa (diciamo dieci o dodici anni fa)
usc� per un breve periodo la moda di mandarsi messaggi
nascosti fra amici mettendo negli header dei campi con
nome X-qualchecosa e chiacchierare l� dei ca##i propri.
Poi qualcuno si stup� che un post di poche righe
pesasse 5-6KB e la moda pass�.
 
Comunque tutt'ora, ogni tanto, ma giusto qualche
volta, capita che qualcuno segnali con quel vecchio
sistema che c'� da sapere qualcosa di pi� di quello
che si pu� dire apertamente, in un post.
 
[no, non andare a guardare: stavolta no :-)]
 
Bye, G. 
 
 

 effettivamente la  " limitazione " che ho descritto
 
diverso tempo fa segnalai che OE presentava il baco quando la riga era 
esattemente superiore a 998 ma inferiore a 1001 ipotizzando che 
probabilmente il baco stava nella routine di controllo che calcolava la 
lunghezza massima di 1000 dimenticandosi di conteggiare i 2 di CRLF: al 
momento dell'invio il server facendo il suo controllo rifutava il post.
Se il references era piï¿œ lungo di 1000 l'errore non si verificava in 
quanto anche OE provvedeva a togliere un M-ID per rientrare nel limite.
 
-- 
Sans

 Almeno a me fa questo.
 
Mai avuto ovviamente il messaggio ...too long...  
e se puo' interessarti (provato e approvato)
 
Su tre server diversi con campo reference di 990
con OE6 base
con OE6 super no multiline
con X-Thunderbird 24
 
viene tolto regolarmente il secondo MID e nel mio caso
diventa 957 e rimane sempre 957 anche con ulteriori post
eliminando sempre l'ulteriore secondo MID
 
*[OT on]*
PS: e mi fanno sorridere i fanatici che parlano di OE.
Non sanno quello che si sono persi e si possono
perdere. Quando passero' ad un SO superiore mi 
faro' fare una partizioncina solo per continuare ad usarlo.
Sperando che ci funzioni...
*[OT off]*
 
          *Isaac ha risposto :*
-- 
*| Ciao P/ero by Isaac :)*
Rat21-Sottotitoli 
http://rat21.altervista.org/
 
Fidolook 2007 (HV) 6.0.6000.96 - 23/12/2007 21:15:48
Windows HE Service Pack 3 Dual attivo da gg 0:2:43:46

 Bye, G.


           *Isaac ha risposto :*
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
Da noi le perle del pensiero sono prodotte dalle cozze.
#v-
 


Mime-Version: 1.0
Content-Type: text/plain;
 charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Trace: 
individual.net
 pXik2BdPFjHRUDfNb2m4wwHzMD/UuGIWcGoKLapualWEZ3DEY=
Cancel-Lock: sha1:kaqt0FcirHoPQi6GxlXxCXPtRvE=
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Face: %v~%/*2L}SZP,Xo6E?`2&gh2v-WZGYpdUzHm!A\258;^TKk|9{?@U6,B94v\CVMM59'z~w]p0\KxqJP]n37COI{}}'X!3+~VEw5GVdg`_",Er|~!C%tmpb,nsS[<z'jd$3x^~rT\(2T0p"!-U<d0H~g.E,>%OCEjm3R{DML,jiEn,'c-@.2~r+q';%^aMAmVH`hoVR,oZHlCCIEp=2vO.O8Gmv-:6EcS3nM<R$s;uxQRd&Td820"w\U+
FL-Build: Fidolook 2008-S (Customized Edition)
The-Day-After: Fri, 16 May 2014 15:33:12 +0200 (Italian-Time)
Xref: 
uni-berlin.de
 it.test:1718281...
 
 
Resto ancora nel dubbio, vediamo se ci provano altri NR come si comportano.
 
    ..._skipped!_
-- 
    * b *
  *   y   *
*   Piero   *
#v+


 Ok, grazie del riscontro. :-)
 
Ed anche col newsreader Piaohong per Android non
riscontro problemi ad inviare 990 caratteri.
 
-- 
Isaac_tab
 
 
 
----Android NewsGroup Reader----
http://www.piaohong.tk/newsgroup
 

 riscontro problemi ad inviare 990 caratteri.
 
Si ok, ma il problema si ha oltre i 998 caratteri messi su una sola riga.
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-deus ex machina-
#v-
 
 

 
 
 
-- 


 Paperino <non...@lo.dico.invalid> ha scritto:

Spedizione anticipata, tastiera virtuale del cappero.
 
...dicevo,  la spezzatura � stata effettuata, non
correttamente, a met� di un MID anzich� in
corrispondenza del primo spazio precedente...
come se non ne avesse trovato uno fra i vari mid.
O come se non lo avesse neanche cercato,
peraltro.
 
Come dicevo di l�, poi provo con TB e con un
invio diretto da programma, a questo punto
voglio proprio vedere che succede.
 
Bye, G.


 "P/ero" <ppi...@woow.it.INVALID> ha scritto:

O non ho capito io o non mi sono spiegato bene
Il fatto e' che che e' *impossibile* superare i 998
caratteri. Con i 2 OE, X-THB e PHG su 3 servernews
diversi quando vengono superati i 998 caratteri
su una sola riga automaticamente viene tolto
il secondo mid presente nella riga dell'header.
Sempre. Ho un thread con un Reference di tale lunghezza
 e posso fare ogni prova possibile. Dimmi te.
Mi e' *impossibile* superare i 998 caratteri.
Fine. 
E batteria pure scarica


 E batteria pure scarica
 
Ricapitolando: � impossibile superare i 998 caratteri
su una sola riga. Ma *� possibile* creare un campo di
lunghezza arbitraria *purch�* lo si spezzi in singole
linee, ognuna di lunghezza inferiore a 998 caratteri.
Controprova su it.test dove ho risposto ad un post di
P/ero con un programmillo apposta, giusto per evitare
le idiosincrasie dei singoli newsreader. C'� il campo
references che occupa pi� di 1500 caratteri.
 
Bye, G. 
 
 

> Non sanno quello che si sono persi
 
Difficile non saperlo. I newsreader microsoft hanno causato tanta
sofferenza ad Usenet quando ancora era viva. Oggi non soffre pi�. :)
 
Scusate l'OT (almeno in questo thread), era solo per ricordare il passato.

 sofferenza ad Usenet quando ancora era viva. Oggi non soffre pi�. :)
 
Bench� sia d'accordo, la cosa mi fa inc##are
ancora di pi� in quanto i veri bug erano
relativamente pochi e in teoria anche facili
da risolvere... volendo. Il fatto � che non
si � mai *voluto*, appunto, risolverli.
 
Il limite dei 2GB per cartella (che non � neanche
un vero bug: � una caratteristica del design
*e* una stronzata, ma non un bug), la gestione
degli headers lunghi (di cui si discuteva
appunto in questo thread), il quoting che non
funzionava in certe combinazioni specifiche
di caratteristiche del post a cui si rispondeva,
e forse qualche altra cosa.
 
Voglio dire, roba che (a patto che il codice
fosse stato scritto in maniera pulita) un
programmatore di mezza tacca avrebbe potuto
risolvere in una settimana o due di lavoro,
predendosela pure comoda.
 
Poi, bug a parte, qualche caratteristica pi�
avanzata avrebbe fatto molto comodo, non dico
di no :-).
 
Bye, G. 
 
 

 passato.
 
Sei il solito fanatico che si intromette solo
per dar fiato alla bocca e disturbare il thread
con la scusa dell'OT.
La Netiquette considera l'OT solo maleducazione
 
-- 
Isaac
 

   di no .
 
Ma di cosa stai parlando ?
Caratteristiche piu' avanzate ?
Ma almeno hai una minima idea di quello che si puo'
fare con OE ? Penso proprio di no.
 
-- 
by Isaac 
 

 references che occupa pi� di 1500 caratteri.
 
E che utilita' dovrebbe avere creare un campo di lunghezza arbitraria
e poi spezzare le singole righe ? Non ha senso
Un newsreader ben fatto (2 OE - X-THB - PHG)  quando arriva al limite
toglie il secondo MID e aggiunge in fondo il nuovo e ultimo MID...
finche il thread finisce o va avanti all'infinito
 
-- 
Isaac
Windows HE Service Pack 3 Dual attivo da gg 0:1:13:47 
 


Questa tua segnalazione risale a molto tempo fa ?
 
+1
 


 
-- 
Sans

 finche il thread finisce o va avanti all'infinito
 
Se si parla di reference. Ma il concetto vale per *tutti*
i campi, non solo per le references.
 
Come ho giï¿œ detto in qualche altro post, possono esserci
altri campi che hanno bisogno di occupare piï¿œ di un migliaio
di caratteri, e vanno in qualche modo gestiti.
 
Bye, G.

"Luca P." [by 40tude_Dialog/
2.0.15.1
 (e65668aa.168.328)] on 15/05/14

Forse non ti sei accorto che non � a me che dovevi rispondere...
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-cogito ergo sum-
#v-
 
 

 caratteri.
 
Vedo che ti ha gi� risposto Paperino...
    ..._skipped!_
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-summum ius summa iniuria-
#v-
 
 

 qualche patch che adesso gli crea problemi
 
Il mio OE gode ottima salute :-D non ha nessun problema.
Si sta solo cazzeggiando sul campo References, o meglio sulla sua
lunghezza secondo le direttive della RFC 5536...
 
E poi, lasciamelo dire: era tanto tempo che non si sviluppava un thread
cos� lungo su questo gruppo, son cose che danno soddisfazione. :-D
 
    ..._skipped!_


 Forse non ti sei accorto che non � a me che dovevi rispondere...
 
Strano, io ho risposto alla persona giusta. Deve essere un altro bug di
Outlook.
 
 
 
 
 
 
;)

 La Netiquette considera l'OT solo maleducazione
 
Ho cambiato subject, quindi quel poco di OT che c'era ora non c'� pi�

 ;)
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
Assolto perch� il fatto non costituisce dibattito.
#v-
 
 

> ;)   <--------------------------
 
Mi sa che era una battuta :-D
 
Bye, G.