fiddler 和 oracle fusion 中间件形式

发布于 2025-01-02 02:51:18 字数 1205 浏览 0 评论 0原文

因此，我试图找出 Oracle Forms 应用程序发送到服务器的内容（可能将其用于负载测试）。 Fiddler 告诉我示例请求的标头如下所示：

POST http://server:9001/forms/lservlet;jsessionid=[long string] HTTP/1.1
Pragma: 81
Content-type: application/octet-stream
Cache-Control: no-cache
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_30
Host: server:9001
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 39

正文看起来像是加密/压缩的。问题是：主体发生了什么（压缩、解密）以及如何获得可读的字符串？或者至少我可以以编程方式发送的字节？

编辑好吧，如果我去 fiddler 的 HexView 那里，我可以看到已发送内容的十六进制表示形式。不过，仍然不清楚客户端如何处理数据包主体。

编辑2 似乎没有人喜欢破解 oracle 表单数据包。不管怎样，为了结束这个，我得出一个结论：如果你发送一个与之前相同的http数据包（就像在表单中模仿搜索） - 服务器会回答

ifError:0/FRM-93618: fatal error reading data from runtime process
Contact your system administrator.

，然后应用程序本身会抛出

    FRM-92104: A network error or server failure has occurred. The request was sent to the
 wrong application server (not the one which created the session). The Forms client has
 attempted to migrate the session %s time(s) without success. You will need to restart your application.

如果有人的话那就太好了可以解释为什么会这样。

原文

So I'm trying to figure out what oracle forms app is sending to server (to possibly use that for load testing). Fiddler tells me that sample request's header looks like this:

POST http://server:9001/forms/lservlet;jsessionid=[long string] HTTP/1.1
Pragma: 81
Content-type: application/octet-stream
Cache-Control: no-cache
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_30
Host: server:9001
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 39

And the body looks like encrypted/compressed. The question is: what happened to the body (compression, decryption) and how do I get readable string? Or at least bytes that I could send programatically?

EDIT
All right, if I go to fiddler's HexView there I have nice hexadecimal representation of what has been sent. Still not clear what client does with packet body, though.

EDIT 2
Seems no one likes hacking oracle forms packets. Anyway, to end this here's a conclusion I've come to: if you send a http packet identical to the one before (like imitating search in a form) - server would answer with

ifError:0/FRM-93618: fatal error reading data from runtime process
Contact your system administrator.

And the application itself would then throw

    FRM-92104: A network error or server failure has occurred. The request was sent to the
 wrong application server (not the one which created the session). The Forms client has
 attempted to migrate the session %s time(s) without success. You will need to restart your application.

Would be great if anyone could shed some light on why this is so.

分享到QQ

分享到微博