here is my debug files let me know if there is anything else i could get you. and yes with UU i did delete the ini file and then replaced it with a working version of the ini still no go it almost seems as if the file is currupted as it uploads as there is no reall error that stands out to me but the special chars that look like 2 little boxes. If you like I can setup a test envirment for you so you can upload with UU your self there. As for now I have set my DF install to allow posting to the site for UU so at this time I am not testing the cookie handling just more or less the ability to post as the last version has been able to work this way.

thank you very much for working with me on this Anaxent. After looking at all of the clues, I am still stumped, so could you please make a testbed for me in which this problem can be recreated? I could actually step through the UU code to see what is happening if I can recreate the bug.

I haven't been able to recreate the problem yet.

Ok np ill get something setup today thx again Matt.

Matt, I wanted to ask about the user agent
Are you going to change it back to being auto generated or is it still going to be customizable?

auto generated,

we dont need custom user agent, and the agent is more useful to you if its auto

Matt_Miller wrote:auto generated,

we dont need custom user agent, and the agent is more useful to you if its auto

Cool, thanks Matt
And yes, it's much more usefull to me (so I can detect UU 2.5.x or higher and set the settings string correctly)

any luck with the testbed anaxent?

Can someone let me use their server to test, ( someone having the blank update problem) please???

ITS LIKE PULLING *(#&$*(@( TEETH GODDDD

I'm sorry everyone, that was uncalled for

Yes i wilol get one ready for you as i do have the sever ready but I do not have files uploaded and installed yet for you I have not had alot of time this last few weeeks to get much of anything done.

Thanks To Anaxent giving me the tools, I found the solution!


I had UU send a request header called "Accept-Encoding" "gzip,deflate"

This caused the server response to be gzip encoded if you view a gzip file as ascii, you will see the two "unreadable characters" (the two boxes in the server response)

as soon as I turned off that request header, the server response came through correctly

I also noticed that the server Anaxent provided me with pukes out an error 403 with any user agent it doesn't recognize, so when I set the User Agent to a known browser (IE 6) It went through.

This means 2 things:

I have to leave the "custom user agent" option in UU
the UU user agent cant be effectivley used for backward/forward compatibility with web interfaces (such as UA or Roster).

I probably wont leave it anyway because of this.

UPDATE:

I was able to decode the error 403 response from the server, the image is attached!

ANOTHER update:

Appearantly this is controllable through the dragonfly CMS admin area:


Because of this I realize that in most cases error 403s due to user agents can be solved by fixing the silly web server settings.

Blocking unknown user agents is silly because the agent can be easily spoofed.

In conclusion, I will disable the custom user agent setting, and anyone who runs into a 403 because of the user agent will have to work it out at the server.

Good job
Glad that's figured out

And I'm also glad that the custom user agent won't be built in for UA's purposes