Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/19/2022 in all areas

  1. MattyD

    Minesweeper

    Hi all, There's not really too much to say here - Just my take on a classic for anyone who's looking for something to disect. Enjoy! minesweeper.au3
    2 points
  2. @sylremo Thanks again for the suggestion to have a function that just returns the request body, if it exists. I will add that functionality to the UDF and publish a new version soon.
    2 points
  3. ISI360

    ISN AutoIt Studio

    Note: This is the continuation thread from the original one of 2012. The old one growed over 50 pages...so to make the overview better i created a new main thread for the ISN AutoIt Studio. You can find the old original thread here. The ISN AutoIt Studio is a complete IDE made with AutoIt, for AutoIt! It includes a GUI designer, a code editor (with syntax highlighting, auto complete & intelisense), a file viewer, a backup system and a lot more features!! Here are some screenshots: Here are some higlights: Easy to create/manage/public your AutoIt projects! Integrated GUI-Editor (ISN Form Studio 2) Integrated file & projectmanager Auto backupfunction for your Projects Extendable with plugins! Available in several languages Trophies Syntax highlighting /Autocomplete / Intelisense Macros Changelog manager for your project Detailed overview of the project (total working hours, total size...) Am integrated To-Do List for your project Open Source (You can download the source code from my website) And much much more!!! -> -> Click here to download ISN AutoIt Studio <- <- Here is the link to the german autoit forum where I posted ISN AutoIt Studio the first time: Link For more information visit my Homepage: https://www.isnetwork.at So, have fun with the ISN AutoIt Studio! And feel free to post your feedback, bugreports or ideas for this project here in this thread!
    1 point
  4. Purpose (from Microsoft's website) The HTTP Server API enables applications to communicate over HTTP without using Microsoft Internet Information Server (IIS). Applications can register to receive HTTP requests for particular URLs, receive HTTP requests, and send HTTP responses. The HTTP Server API includes SSL support so that applications can exchange data over secure HTTP connections without IIS. Description There have been several times in the past that I wanted to either retrieve information from one of my PCs or execute commands on one of my PCs, whether it was from across the world or sitting on my couch. Since AutoIt is one of my favorite tools for automating just about anything on my PC, I looked for ways to make to make it happen. Setting up a full blown IIS server seemed like overkill so I looked for lighter weight solutions. I thought about creating my own AutoIt UDP or TCP servers but that just wasn't robust enough, Then I found Microsoft's HTTP Server API and it looked very promising. After doing a little research into the APIs, I found that it was flexible & robust enough to handle just about any of the tasks that I required now and in the future. So a while back I decided to wrap the API functionality that I needed into an AutoIt UDF file to allow me to easily create the functionality I needed at the time. It has come in very handy over the years. Of course it wasn't all wrapped up with a nice little bow like it is now. That only happened when I decided to share it with anyone else who could use it or learn from it. The example file that I included is a very granular example of the steps required to get a lightweight HTTP Server up and listening for GET requests. The UDF is a wrapper for the Microsoft APIs. That means to do anything over and above what I show in the example, one would probably have to have at least a general knowledge of APIs or the ability to figure out which APIs/functions to use, what structures and data is needed to be passed to them, and in what order. However, the UDF gives a very solid foundation on which to build upon. Of course, if anyone has questions about the UDF or how to implement any particular functionality, I would probably help to the extent that I could or point you in the right direction so that you can figure out how to implement your own solution. Being that this is basically an AutoIt wrapper for the Microsoft API functions, there's no need to create AutoIt-specific documentation. All of the UDF functions, structures, constants, and enumerations are named after their Microsoft API counterparts. Therefore, you can refer to Microsoft's extensive documentation of their HTTP Server API. The APIs included in the UDF are the only ones that I have needed in the past to do what I needed to do. If you would like any additional APIs to be added to the UDF file, please suggestion them. Related Links Microsoft HTTP Server API - Start Page Microsoft HTTP Server API - API v2 Reference Microsoft HTTP Server API - Programming Model >>> See screen shots and DOWNLOAD in the Files section <<<
    1 point
  5. Version v1.4.0

    827 downloads

    Purpose (from Microsoft's website) The HTTP Server API enables applications to communicate over HTTP without using Microsoft Internet Information Server (IIS). Applications can register to receive HTTP requests for particular URLs, receive HTTP requests, and send HTTP responses. The HTTP Server API includes SSL support so that applications can exchange data over secure HTTP connections without IIS. Description There have been several times in the past that I wanted to either retrieve information from one of my PCs or execute commands on one of my PCs, whether it was from across the world or sitting on my couch. Since AutoIt is one of my favorite tools for automating just about anything on my PC, I looked for ways to make to make it happen. Setting up a full blown IIS server seemed like overkill so I looked for lighter weight solutions. I thought about creating my own AutoIt UDP or TCP server but that just wasn't robust enough, Then I found Microsoft's HTTP Server API and it looked very promising. After doing a little research into the APIs, I found that it was flexible & robust enough to handle just about any of the tasks that I required now and in the future. So a while back I decided to wrap the API functionality that I needed into an AutoIt UDF file to allow me to easily create the functionality I needed at the time. It has come in very handy over the years. Of course it wasn't all wrapped up with a nice little bow like it is now. That only happened when I decided to share it with anyone else who could use it or learn from it. The example file that I included is a very granular example of the steps required to get a lightweight HTTP Server up and listening for GET requests. The UDF is a wrapper for the Microsoft APIs. That means to do anything over and above what I show in the example, one would probably have to have at least a general knowledge of APIs or the ability to figure out which APIs/functions to use, what structures and data is needed to be passed to them, and in what order. However, the UDF gives a very solid foundation on which to build upon. Of course, if anyone has questions about the UDF or how to implement any particular functionality, I would probably help to the extent that I could or point you in the right direction so that you can figure out how to implement your own solution. The APIs included in the UDF are the ones that I needed in the past to do what I needed to do. If any additional APIs need to be added to the UDF file, please make those suggestions in the related forum topic. Being that this is basically an AutoIt wrapper for the Microsoft API functions, there's no need to create AutoIt-specific documentation. All of the UDF functions, structures, constants, and enumerations are named after their Microsoft API counterparts. Therefore, you can refer to Microsoft's extensive documentation of their HTTP Server API. As stated earlier, if there is one or more APIs that you find yourself needing for your particular solution, please suggest it in the related Example Scripts forum topic. Related Links Microsoft HTTP Server API - Start Page Microsoft HTTP Server API - API v2 Reference Microsoft HTTP Server API - Programming Model
    1 point
  6. You're right, it's not visible in the response headers. That's because it does not exist in the response headers. Referrer is a request header. Request headers describe the request and response headers describe the response. So why would you expect to see that request header ("Referrer") returned by a method named GetAllResponseHeaders? There's not a GetAllRequestHeaders method because you are the one building and sending the request so you know what request headers are being sent. Of course, this assumes that your request was successful. 😉
    1 point
  7. The example included with the UDF only processes GET requests. Ordinarily, GET requests do not include a body. The quick example file that I have attached below, recognizes and processes POST requests. In the attached example, in the process_post_request() function, you will see how I parse the body into a variable and display the body of the POST request in the response and to the console. The example is made to be run in the scite editor because it shows details about the request in the console window. Yes, that is the way that Microsoft's HTTPAPI works. You create URL groups and assign those URL groups to request queues. Requests go into the queues and get processed accordingly. Microsoft's HTTPAPI is a true, standards-based, web server. My UDF gives a framework to implement some of its functionality using the included API wrappers. One of the other nice things about using Microsoft's HTTPAPI as a web server is that it has the ability to handle secure communications (TLS) transparently. In other words, other than binding a valid certificate to your specific ip:port (or hostname:port in Windows 10+), you don't need to do anything special in the code. It just works. The UDF was originally created for my personal use, not for public consumption. I decided to make it fit AutoIt UDF standards and share it in case others might find it as useful as I do. I have scripts that use the UDF to process RESTful GETs, POSTs, and all sort of requests. Although I have had no plans to add functionality, I do take and implement features that are requested, if I think they are useful and would be widely used by others. Of course, if someone finds a bug I will squash it as soon as possible. There are examples of how to add headers to a response in the example script that comes with the UDF. The parsing of a request path is in the example also. There's not an example of processing RESTful parameters in the request path, but that is simple string manipulation. However, I could see writing a generic function that parses the path and places the key/value parameters into a dictionary object or map. In any case, I appreciate the suggestions Thanks! example_http_server_get_post_requests.au3
    1 point
  8. The latest version available seems to be running fine it now for me. Just for clarity: The Dynamic UDF's syntax coloring will be refreshed when you: Open an AU3 file Change buffer to another AU3 file. This means it will not refresh when you change from x.AU3 to a Y.LUA and then back to x.AU3. Save an AU3 file. So in case you create a new UDF in your current sourcefile, it will only start showing a color of the Dynamic UDF's when a save is performed or switch to another AU3 file and back. Let me know when there are questions on the above. Jos
    1 point
  9. Having absolute no experience in working with DLLs or any C/C++ documentations, it takes me a while to write my own function to retrieve the request body... Func _HTTPAPI_GetRequestBody($tRequest) Local $tDataChunks = DllStructCreate($__HTTPAPI_gtagHTTP_DATA_CHUNK_FROM_MEMORY, $tRequest.pEntityChunks) If ($tRequest.EntityChunkCount < 1) Then Return "" Local $sBody = DllStructCreate(StringFormat('char data[%i]', $tDataChunks.pBufferLength), $tDataChunks.pBuffer).data Return $sBody EndFunc I've done a test of your UDF with others in this forum, i've noticed a huge different. When handling huge amount of requests concurrently, while other UDFs will eventually ignore some latter requests, yours really put these requests into queue and handle them one by one perfectly without any failures. In future versions, I hope to see a better implement of this. Adding customizations to response's header and auto parse url/query params (eg: ../user/:param1/action?key1=value1&key2=value2) would also be nice. Great work btw!
    1 point
×
×
  • Create New...