camikusch,
camikusch wrote:
> the example i posted happen to send less then 1024bytes of data to the
> webserver which is fine, but when the amount of data exceeds 1023 byte
> (pdfformfield names and the associated data) adobe reader sends a "expect
> 100-continue" header...
According to the HTTP/1.1 specification, "The purpose of the 100 (Continue)
status is to allow a client that is sending a request message with a request
body to determine if the origin server is willing to accept the request
(based on the request headers) before the client sends the request body. In
some cases, it might either be inappropriate or highly inefficient for the
client to send the body if the server will reject the message without
looking at the body."
Adobe Reader seems to consider sending 1 KB or more body data as
inappropriate or inefficient if the server rejects the message due to the
headers. An acceptable assumption.
camikusch wrote:
> adobe reader sends a "expect 100-continue" header which isnt correctly
> handled by lighttpd...
>
> 2010-06-08 08:19:57: (request.c.304) fd: 8 request-len: 207
> POST /get_post_vars.php HTTP/1.1
> User-Agent: AcroForms
> Host: localhost
> Accept: */*
> Content-Type: application/x-www-form-urlencoded
> Acrobat-Version: 9.3.2
> Content-Length: 1130
> Expect: 100-continue
>
> 2010-06-08 08:19:57: (response.c.128) Response-Header:
> HTTP/1.1 417 Expectation Failed
> Content-Type: text/html
> Content-Length: 363
> Connection: close
> Date: Tue, 08 Jun 2010 06:19:57 GMT
> Server: lighttpd/1.4.26
Actually the behaviour of lighttpd is completely correct; according to the
HTTP/1.1 specification, "A server that does not understand or is unable to
comply with any of the expectation values in the Expect field of a request
MUST respond with appropriate error status. The server MUST respond with a
417 (Expectation Failed) status if any of the expectations cannot be met or,
if there are other problems with the request, some other 4xx status."
camikusch wrote:
> adobe reader sends expect-100, 300seconds after that the php script
> continues *without having received the post-data* to send the answer pdf
> which is received normally by the reader.
Hhmmm, 300 seconds seems a very long time for the Acrobat Reader to wait for
the 100 (Continue) status. According to the HTTP/1.1 specification, "Because
of the presence of older implementations, the protocol allows ambiguous
situations in which a client may send "Expect: 100- continue" without
receiving either a 417 (Expectation Failed) status or a 100 (Continue)
status. Therefore, when a client sends this header field to an origin server
(possibly via a proxy) from which it has never seen a 100 (Continue) status,
the client SHOULD NOT wait for an indefinite period before sending the
request body."
This is but a recommendation for the client ("SHOULD"), though, while the
server has to be able to properly handle the expect header. Therefore, your
server-side applications need to be fixed after all.
Regards, Michael.
--
View this message in context:
http://itext-general.2136553.n4.nabble.com/max-number-of-comboboxes-in-a-pdfform-is-85-tp2240100p2247278.html
Sent from the iText - General mailing list archive at Nabble.com.
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
