Issue 74980 - HTTP POST which results in a redirect does not work
Summary: HTTP POST which results in a redirect does not work
Status: CLOSED FIXED
Alias: None
Product: ucb
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: thorsten.martens
QA Contact: issues@ucb
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-28 15:19 UTC by Frank Schönheit
Modified: 2007-07-05 11:59 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
document to reproduce the bug case (7.34 KB, application/vnd.oasis.opendocument.text)
2007-02-28 15:22 UTC, Frank Schönheit
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2007-02-28 15:19:29 UTC
This is a follow-up from issue 74484, which describes that HTTP POSTs do not
work in OOo forms anymore. This is fixed with issue 74484, but there's another
problem: If the POST results in a redirect, then this doesn't work anymore.

To reproduce:
- open the attached document
- enter "Base" in the input field
- press the "Search" button

This is expected to open the "Base" page of the OOo-Wiki. Internally, it starts
a HTTP-Post to the Wiki's search page, and since the search term is the exact
match of the title of an existing page, the Wiki redirects the request to this page.

Actually, nothing happens at all.

fs->abi:
The first POST request returns a (NE_REDIRECT/DAV_HTTP_REDIRECT) (after issue
74484 is fixed). This seems to be handled by issueing a new request. However,
there's two problems with this second request:
- In NeonSession::getDataFromInputStream in the WebDAV provider, the
  input stream is not moved to position 0. That is, in the second attempt to open
  the redirected page, getDataFromInputStream fails, since the input stream
  cannot provide any data anymore (it's at EOF, from the previous call).
- Even when this is fixed with a xSeekable->seek(0) in getDataFromInputStream,
  then the second attempt fails. This seems to be (just guessing here) because
  the UCP is again trying to POST to the redirected URL, instead of just
  opening it.
Comment 1 Frank Schönheit 2007-02-28 15:20:50 UTC
2.3, since it's effectively the same target requirement as for issue 74484.
Comment 2 Frank Schönheit 2007-02-28 15:22:12 UTC
Created attachment 43440 [details]
document to reproduce the bug case
Comment 3 andreas.bille 2007-03-14 18:26:38 UTC
accepted
Comment 4 kai.sommerfeld 2007-03-21 15:22:27 UTC
I will take a look at this.
Comment 5 kai.sommerfeld 2007-03-21 15:23:15 UTC
.
Comment 6 kai.sommerfeld 2007-04-20 11:21:55 UTC
Server responds with 302 (Moved temporarily).  RFC2616 (HTTP) states re this
response:

=======================

10.3.3 302 Found

[...]

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.

=======================

Thus, I think it is a good idea to change OOo's HTTP client behavior to be like
"most existing user agent implementations".
Comment 7 kai.sommerfeld 2007-04-20 15:21:01 UTC
Fixed. Now, upon redirect on a POST, a GET will be done.
Comment 8 kai.sommerfeld 2007-05-04 12:26:05 UTC
kso->tm: Please verify.
Comment 9 thorsten.martens 2007-05-09 10:01:12 UTC
checked and verified in cws ucbfixes01 -> OK !
Comment 10 thorsten.martens 2007-07-05 11:59:33 UTC
closed